What is required to enable marshaling for a COM interface?

Question

I have a 32-bit ATL COM component without a type library. It has a class factory for one given class that implements several interfaces.

When I use it as an in-proc server, everything works fine - the client side invokes CoCreateInstance(), the object is instantiated and QueryInterface() retrieves a pointer to a requested interface. But when I put the component into COM+ I no longer can instantiate the class - CoCreateInstance() now returns E_NOINTERFACE.

I believe the problem is that COM+ can't perform marshaling because of absence of type library - it has no idea how to do it. Do I need to generate and register a type library to resolve this or is there any other way?

Cykana

The ATL project wizards normally set up to have a typelib, embedded as a resource in the project output and registered with the coclasses. – Mastermind

Yes, I know that. The problem is I implement an interface already defined by Microsoft for which no idl file or type library is provided. That's why I'll have hard time reinventing the type library full of custom-defined types. – Cykana

fyi, it's "marshaling" in the context of COM, "marshalling" in the context of Java. :-) – Dogs

Answer 1

Urk. I would recommend asking on microsoft.public.vc.atl as I think you will find more experts there. I think (though I'm not an expert) the issue has less to do with COM+ than the issue of registered proxy/stubs. (In other words, even if you wrote your own COM client to access your component out-of-process, you would probably run into the same issue) If you have standard Automation-compatible interfaces, then Windows knows how to marshal your objects just fine. But otherwise it is confused.

Without a type library, you either need to register proxy/stubs, or need to implement IMarshal yourself to handle custom marshaling. (or there's also this "handler marshaling" thing that I don't understand)

Your comment about why you don't have a type library (implementing an interface already defined by Microsoft, but one which doesn't have a typelib) raises a red flag with me. Can you provide more details? If it's something in a .DLL or .EXE, but the type information is inside the library itself (rather than an external .TLB file) it's probably possible to extract the right information to make everything work, I'm just not familiar with the process.

(For the record, I've left ATL/COM programming in favor of Java, so although I can let you know what I remember in the past, I don't use the tools now and it would be difficult for me to get back into them to provide any more help. But the folks on the microsoft.public.vc.atl are pretty smart.)

Dogs

If the ATL usenet group provides any help, please recap the information here. – Pontificals

I found the .idl file in the later version of Microsoft SDK. I could include it into the project and that would solve the problem. But the interface is not Automation-compatible because of multiple custom types. So I introduced my own interface that could be happily marshalled and created a frontend component that implemented the original interface and tunneled calls to my component. This way it works through COM+ and I now need to create a 64-bit version for the frontend only and not for all the stuff the inner component depends on. – Cykana

Answer 2

Typelibs are one way to support marshalling, proxy/stub DLLs (genereated from the IDL) are another. In both cases, however, you'll need the IDL in the first place.

If Microsoft does not provide a typelib/proxy DLL or IDL for this interface, odds are that there is a reason for this: Maybe the interface uses non-marshalable data structures, requires function pointers to be passed as method parameter or things like this? If this is the case, there is just no way to make this interface work for DCOM.

Maybe you can reconstruct the IDL, but quite possibly, it just will not be feasible. Then your last fallback could be to use custom or handler marshalling, but that's probably not worth the effort. That said, I'd recommend considering other routes that does not involve using interfaces for DCOM that were not designed to be used for DCOM.

Wamble

Answer 3

For an COM interface to be marshallable using Microsoft's default marshaller, the interface has to have either the DUAL or the OLEAUTOMATION property defined in its header.

If there are arguments for the methods defined that are interface pointers, the same requirement extends to those interfaces.

Plus the interface name must be present in the LIBRARY section of the IDL defining it. This also extends to other referenced interfaces.

If these conditions are not met, the interface won't be marshallable.

Plasma