Create remote object to run in stathread apartment

[sanjeev]

We are attempting to the following -

Create an activex control in a remote object and call methods in the
control. The only way I can get the activex control instantiated is by
spawning a new worker thread, setting its ApartmentState to stathread
and creating the activex control in this worker thread. The remoting
object is running in an mtathread apartment. Is there a way to have it
run in an stathread apartment, so that we could avoid spawning the
worker thread?

Regards,
SK

 

[Willy Denoyette [MVP]]

We are attempting to the following -

Create an activex control in a remote object and call methods in the
control. The only way I can get the activex control instantiated is by
spawning a new worker thread, setting its ApartmentState to stathread
and creating the activex control in this worker thread. The remoting
object is running in an mtathread apartment. Is there a way to have it
run in an stathread apartment, so that we could avoid spawning the
worker thread?

Regards,
SK

No there isn't. More, your scenario is broken. ActiveX controls aren't
designed to run in a server context. A remoting server must be able to run
on a server that has no active interactive logon session. In such scenario
your code will break.
Never forget, ActiveX is a client side technology which requires a STA host
and a AX control container (a Windows form, MFC form, VB form, office form
etc...) to run in.


Willy.

 

[sanjeev]

Your suggestion is well taken. We would have preferred that the
functionality in the control was exposed in the form of a DLL/Library.
But since it is a third party control we have limited choice.

The container will have no user-interaction with the ActiveX control,
but will make a handful of calls. As mentioned earlier the control can
be instantiated after spawning a thread whose ApartmentState is
assigned to stathread. However, we are not too happy with this
mechanism.

 

[Willy Denoyette [MVP]]

Your suggestion is well taken. We would have preferred that the
functionality in the control was exposed in the form of a DLL/Library.
But since it is a third party control we have limited choice.

Yes you have don't use it, the reason is simple, the third party did not
author the component to be used in such scenario, isn't that enough a
reason?

The container will have no user-interaction with the ActiveX control,
but will make a handful of calls. As mentioned earlier the control can
be instantiated after spawning a thread whose ApartmentState is
assigned to stathread. However, we are not too happy with this
mechanism.

This is not a matter of user interaction, it's a matter of incorrect
non-available interfaces. ActiveX is designed for client side code, must run
in a STA thread that pumps messages (bet that you don't pump the message
queue!) to begin with, failing to do so will bite you back, especially in a
CLR environment where COM interop is not as forgiving as a VB environment
(think memory leaks failing object disposals etc...).
If you use ActiveX components server side you introduce a bug in your
application, sooner or later it will bite you.

Willy.

 

[sanjeev]

The third party, a partner of ours, erred in the choice of housing for
their services. That has led us to this in the first place. Ideally the
services in this particular ActiveX control should have been broken up
into a regular/COM DLL and an ActiveX control. However, with the
current design we are stuck with the ActiveX control and we need to use
a small subset of the ActiveX services, that does not need any user
interaction. Ideally this subset should have been put in a Win32 DLL or
a COM component.

I appreciate your advice regarding the risk of using ActiveX on the
server side. I do not like it, however until we have a newer version of
the server, we are constrained to use what we have at present.