I’m analyzing a rather old COM server project in order to reuse some stuff from it and noticed a strange thing – in order to expose itself to the registry it implements a separate function different from DllRegisterServer() and that function accepts the path to the typelib and loads the typelib from that path and the typelib is shipped separately and can be located anywhere.
The typical solution is to just use ATL CComModule::RegisterServer() which will happily load the typelib from the same DLL if it is embedded as a resource. The DLL already uses ATL and this should be the most direct way.
I tried to find why the typelib is not embedded as a resource but looks like it was a very old design decision and noone can explain it.
I can see a reason for shipping the typelib separately – this way it’s easier for COM server developers to #import it. But why not both ship it as a separate file and embed as a resource into the COM server DLL? I could imagine that the typelib increases the DLL size by several hundred kilobytes but can’t find any other serious reason.
What could be the reasons for shipping the typelib as a separate file only?
I finally found a serious reason for shipping a typelib separately only. If two versions – standalone and embedded – are shipped the installer could screw something up and those two typelibs could come out of sync and this would cause all kinds of weird problems for customers. Shipping exactly one version of typelib is safer in this aspect.