Registry keys for out-of-process COM server

Question

I'm in the process of implementing my first out-of-process COM server (my first COM server altogether, for that matter). I have followed the steps to write an IDL file, generate the code for the proxy/stub DLL, compile the DLL, and register it.

When I check the registry keys, I have

• A key named HKEY_CLASSES_ROOT/Interface/<GUID>, whose vaue is (say) IMyApp and
• A key named HKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32, whose value is <GUID>, i.e. the same value as in the key name

I don't understand how the the second key's value can be the same <GUID> value as in the key name, because my current understanding is that

• In HKEY_CLASSES_ROOT/Interface/<GUID>, GUID is an interface ID
• The value of ProxyStubClsid32 is not an interface ID, but a class ID referring to the component that implements the above interface
• The value of HKEY_CLASSES_ROOT/CLSID/<GUID>/InprocServer32 (where GUID is the above class ID) points to the proxy DLL

How, then, can the value of HKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32 hold the same value GUID if one is an interface ID and the other is a class ID?

EDIT: I'm still hoping for an answer to this one. To put it short: Since a component and an interface are two different things, how can the same ID be used for both?

Answer 1

Your basic understanding of the way Guids are used in COM is correct. Notable first is that an interface and a coclass having the same guid is not a problem. They live in different registry keys, HKCR\Interface vs HKCR\CLSID and it is always clear in COM whether you are looking up a IID or a CLSID.

Second is the IDL you wrote. Note that there's no place there to specify the CLSID of the proxy, only the IIDs supported by the proxy and stub can be declared there.

Next, you need a wild goose chase through the way that the proxy/stub is autogenerated. The core Windows SDK header is RpcProxy.h, open it in a text editor to have a look see. The macro soup is very heavy but it does have a few decent comments that describe what's going on. The important RPC helper function is NdrDllRegisterProxy(), it registers the proxy and is called when you use Regsvr32.exe. Its 3rd argument specifies the CLSID of the proxy. I'll let you do the reading and just quote the important bits in the .h file:

Compiler switches:

-DPROXY_CLSID=clsid
    Specifies a class ID to be used by the proxy DLL.

This one you specify with Project + Properties, C/C++, Preprocessor, Preprocessor Definitions setting. Note that your project will not specify it.

Chasing through the soup then lands you on this one:

// if the user specified an override for the class id, it is
// PROXY_CLSID at this point

#ifndef PROXY_CLSID
#define GET_DLL_CLSID   \
    ( aProxyFileList[0]->pStubVtblList[0] != 0 ? \
    aProxyFileList[0]->pStubVtblList[0]->header.piid : 0)
#else  //PROXY_CLSID
#define GET_DLL_CLSID   &PROXY_CLSID
#endif //PROXY_CLSID

In other words, if you didn't specify the CLSID yourself (you didn't) then it uses the first IID in the stub table.

And that makes the ProxyStubClsid32 guid the same as the IID of your first interface. Feature, not a bug.

Answer 2

A case of Beginner's Confusion (tm). The class registered by calling regsrv32 is not the one with my CLSID. It is one generated specifically for the proxy/stub DLL (the friendly name PSFactory also indicates this). So as Roman R. suspected, there are two classes where I thought there was only one. My own CLSID is registered by the EXE server when it's called with the /Embedding switch.

Answer 3

For what i know, all the proxy/stub mayhem is managed now by the MIDL (inheriting from IDispatch not IUnknown, which you probably already do because you have the ProxyStubClsid32 reg key).

The only thing needed is to register the server properly (just building it or doing /RegServer did not register it properly for us... and for many others), to do so just a call to LoadTypeLibEx is needed (after building the server or installing it).

So just create a small exe with this code and call it after building and on installation:

String^ l_TLB = l_Path + "\\MyServer.tlb";
IntPtr  l_TLBP = System::Runtime::InteropServices::Marshal::StringToBSTR(l_TLB);
ITypeLib *pTypeLib;
HRESULT hr = LoadTypeLibEx(static_cast<LPCOLESTR>(l_TLBP.ToPointer()), REGKIND_REGISTER, &pTypeLib);
if(SUCCEEDED(hr))
    pTypeLib->Release();