0

I am going through a code that has a exe having a COM server(a COM class implemented in ATL). It has a .idl file having all interfaces defined. Now after registration of the COM server, i went through the registry entries and i could find the following. Each interface has a entry with its IID and having ProxyStubClsid32. There is one interface which is implemented by the COM server that i mentioned, which has IID in key field = the value of ProxyStubClsid32 and every other interface interface entry is having this same IID entry in its ProxyStubClsid32 field. Why this is so ??

Next when i try to add a new interface and new COM component implementing this interface to the exe, and do its registration what i could observe in registry was that now IID entry for this new interface and its ProxyStubClsid32 are same. And the newly added IID is present in ProxyStubClsid32 of all other interfaces now.

What gets into ProxyStubClsid32, how is this decided?

I want the previous IID to be present in ProxyStubClsid32 even after adding my new interface. How can i do this ??

Also does explorer.exe caches this registry entry as i am implementing a shell extension which loads the component, i think it is referring to old entries so querying the new interface on that exe doesnt work. Once i restart explorer.exe everything works fine.

Could anyone also comment on this.

Answer to this seems has some hints to my problem : Registry keys for out-of-process COM server

Thanks in advance.

Community
  • 1
  • 1
Raviraj JOshi
  • 1
  • 1
  • Everything you describe is perfectly normal. MIDL picks the IID of the first interface in the IDL file as the CLSID of the proxy/stub. So you probably added the new interface at the top. Not an issue, it clearly got re-registered properly. Having to restart Explorer is normal as well. – Hans Passant Mar 30 '13 at 16:37
  • Is there any way i can resist MIDL from picking the new IID that i have added and make it pick up the IID that it was initially picking so that i dont have to restart explorer.exe ?? – Raviraj JOshi Mar 31 '13 at 09:59
  • I already mentioned that. Don't put the new interface at the top. – Hans Passant Mar 31 '13 at 10:39
  • Are you referring to position in .idl file ? – Raviraj JOshi Mar 31 '13 at 12:59
  • I haven't added it at top in .idl file, neither the earlier interface which is shown up in ProxyStubClsid32 field of all other interfaces was at top of idl file. – Raviraj JOshi Mar 31 '13 at 13:00
  • Where will get to learn about this concept more ? I referred Inside COM book, it only talks about ProxyStubClsid32 being the Clsid of the proxy dll, it doesnt talk about IID of first interface in .idl being used as Clsid of ProxyStubClsid32. Where can i learn more about this ? – Raviraj JOshi Apr 01 '13 at 05:17

1 Answers1

0

What is in ProxyStubClsid32 is actually the interface used for marshalling by the MIDL. It is used because your interfaces inherit from IDispatch and is needed so the compiler takes care of marshalling (as its an OOP server, you NEED marshalling).

For our team we had some problems registering the server in some of the machines (/RegServer was not enough), but using a small exe with this code fixed all registration issues (and thus the E_NOINTERFACE problem that you may have), just call it after every build or on installation:

// Register the server
            String^ l_TLB = l_Path + "\\MyServer.tlb";
            IntPtr  l_TLBP = System::Runtime::InteropServices::Marshal::StringToBSTR(l_TLB);
            ITypeLib *pTypeLib;
            HRESULT hr;
            hr = LoadTypeLibEx(static_cast<LPCOLESTR>(l_TLBP.ToPointer()), REGKIND_REGISTER, &pTypeLib);
            if(SUCCEEDED(hr))
                pTypeLib->Release();
Dario Durà Armadans
  • 21
  • 5