Once I add a COM server into a COM+ server application I can no longer instantiate it in-proc - why?

Question

I have a 32-bit COM server DLL and need to use it from both 32-bit and 64-bit applications. I can create a COM+ server application and then the COM server will be instantiated in a surrogate process.

The problem is I can no longer instantiate it as an in-proc server ( CLSCTX_INPROC_SERVER flag passed to CoCreateInstance() ) - I get "class not registered". This is not very good, because now even 32-bit applications need to talk to the surrogate process and this adds unnecessary marshalling overhead.

How can I set up a COM+ server application in such way that clients of same bitness can still use the COM server in-proc?

Answer 1

32-bit DLLs can only be loaded in 32-bit processes, and 64-bit DLLs in 64-bit processes (reasons are different pointer sizes, but also calling conventions). So it is not possible to use a COM object from a 32-bit in-process server DLL in a 64-bit application, because the system will not load the DLL. Windows Registry also has two different views, one for 64-bit apps and one for 32-bit apps. Your library and interfaces and coclasses from the 32-bit DLL are registered in the 32-bit view, so they are not visible to the 64-bit apps, that's why you get that message.

You need a workaround for that, and the most simple workaround is to create a 32-bit out-of-process executable that hosts a wrapper COM, that acts as a proxy (or facade) for the former COM object. In your 64-bit application you will use this new wrapper. You can read more about that here: http://www.dnjonline.com/article.aspx?id=jun07_access3264 .

Answer 2

That is probably related to COM+, which keeps a cache of recently activated objects. See the comments below this article .