views:

198

answers:

2

There's Another Company that ships the product that consumes IAnotherCompanyInterface. We want to ship a COM object that implements IAnotherCompanyInterface. That interface is not Automation-compatible, so the next easiest option to enable marshalling is using a proxy/stub. Another Company doesn't ship the proxy/stub and doesn't want to.

Compiling and registering the proxy/stub is not a problem by itself but consider the following situation. There's our company shipping a COM object implementing IAnotherCompanyInterface and the ThirdPartyCompany that does the same. So both components might end up being deployed on the same machine.

Proxy/stub registration is system-wide for an interface. How should their proxy/stub implementations co-reside?

A: 

You can skip the registry in your client altogether by using reg-free COM or activation context. You can provide "custom" comInterfaceExternalProxyStub entries in the manifest file that reference you proxy/stub implementation.

wqw
I don't control the client, I only control the COM server.
sharptooth
Nevertheless, you can still assign a manifest with comInterfaceExternalProxyStub entries either as a .manifest file or embedded resource. This looks very much like the "interception" part of COM "interception, delegation, transparent proxies" promise :-))
wqw
A: 

It's a while since I worked with this stuff, so this is "thinking aloud" but hopefully it'll be some help...

I presume that you can see a type library that describes the interface you want to implement. If so, load it into oleview.exe. Copy the IDL it gives you into a new .idl file of your own, and base your own implementation on that file.

I know your question is actually about the proxy/stub DLL. That's fine. Yours will be generated along with your actual COM server, and it will work on your machines and those of your users. If your code is installed on a machine that also has "Another Company's" bits installed, it shouldn't matter...

The proxy/stub is just a bit of code that tells COM how to transfer params and return values between COM client and COM server. If yours is built from IDL that was generated from their typelib, they will be functionally equivalent. Your COM server can be successfully called via their proxy/stub and vice versa.

However, if they change their proxy/stub, they might no longer be functionally equivalent. But in that case, they probably also changed the interface and your COM server would no longer be usable by their client.

Martin
Let's pretend that the interface never changes. So I guess there's no difference in whose proxy/stub is used. Now if there's another company's product there and I install mine - what should I do with the stub - register mine or leave theirs? What if their product is deinstalled and also removes the proxy/stub?
sharptooth
Yes, I see the dilemma. It seems somehow wrong to overwrite their registration with your own. I guess the ideal solution would be to leave theirs intact if it already exists, but if theirs is subsequently deinstalled you should be able to detect the absence of the proxy/stub and gracefully install your own.
Martin
I guess I could do that when the consumer calls CoGetClassObject. Perhaps the problem lies in the fact AnotherCompany introdcues an interface but doesn't ship a proxy/stub.
sharptooth

related questions