What is needed for marshaling for a COM interface?

Question

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

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

I believe the problem is that COM + cannot marshal due to the lack of a type library - it has no idea how to do this. Do I need to generate and register a type library to eliminate it, or is there any other way?

Answer 1

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

Without a type library, you need to either register proxies / stubs, or you need to implement IMarshal yourself to handle custom marshaling. (or there is also this “marshaling handler”, which I don’t understand)

Your comment on why you don’t have a type library (implementation of an interface that is already defined by Microsoft, but one that does not have typelib) causes me a red flag. Can you provide more details? If this is something in .DLL or .EXE, but the type information is inside the library itself (and not the external .TLB file), you can probably extract the necessary information for everything to work, I'm just not familiar with the process.

(For the record, I left ATL / COM programming in favor of Java, so although I can tell you what I remember in the past, I don’t use tools now, and it will be difficult for me to return to them to provide additional help. But people on microsoft.public.vc.atl is pretty smart.)

Answer 2

Typelib is one way to support sorting, the proxy / stub DLL (genereed from IDL) is another one. However, in both cases, you will need an IDL.

If Microsoft does not provide a typelib / proxy or IDL DLL for this interface, there is a possibility that there is a reason for this: perhaps the interface uses unshared data structures, requires function pointers to be passed as a method parameter, or things like that? If so, there is simply no way to make this interface for DCOM.

Perhaps you can restore the IDL, but it is quite possible that this will not be possible. Then your last reserve might be to use custom or handler sorting, but this is probably not worth the effort. However, I would recommend considering other routes that are not connected with the use of interfaces for DCOM, which were not intended for use in DCOM.

Answer 3

For a COM interface that can be marched using Microsoft's default marshaller, the interface must have either the DUAL or OLEAUTOMATION property defined in its header.

If there are arguments for certain methods that are interface pointers, then the same requirement applies to these interfaces.

In addition, the interface name must be present in the LIBRARY IDL section that defines it. This also applies to other reference interfaces.

If these conditions are not met, the interface will not be marchable.