0

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?

4

1 回答 1

0

我终于找到了一个单独发布 typelib 的重要原因。如果两个版本——独立的和嵌入式的——交付安装程序可能会搞砸,这两个类型库可能会不同步,这会给客户带来各种奇怪的问题。在这方面,只发布一个版本的 typelib 会更安全。

于 2011-03-01T07:15:44.990 回答