tags:

views:

283

answers:

1

I've been using a 32 bit COM library by registering it with regsvr32 and all works fine. Since I need to access it from a 64 bit process, I'm now registering it as COM+ through the Component Services administrative tool. Problem is, it seems that not all of the COM interfaces are exposed anymore. What could be the reasons for this?

+1  A: 

There're two aspects of this problem.

First, you manually control which classes are exposed through COM+ by adding these classes only into the COM+ application. The classes you don't include will be instantiated in-proc and this instantiation will just fail because of 32-bit/64-bit incompatibility.

Then comes marshaling. In order to give the consumer an interface pointer of the newly created object COM+ needs to know how to marshal that interface. Unless you implement marshalling on your own default marshalling is used. Default marshalling will work only if the following requirements are met: the COM server contains a type library, the interface is included into that type library and the interface is fully Automation-compatible. The latter roughly means that none of that interface's methods have parameters of custom types like structs for example (interfaces are okay). If these requirements are not met COM+ will return E_NOINTERFACE when the consumer invokes CoCreateInstance() or IUnknown::QueryInterface(). See this similar question: http://stackoverflow.com/questions/852497/what-is-required-to-enable-marshaling-for-a-com-interface You basically have three choices: not query the violating interface, implement custom marshalling (which I don't currently know where to start with) or introduce a new intermediate interface which would be Automation-compatible.

sharptooth