为啥不将 typelib 嵌入到 COM 服务器中并单独发布呢？

Posted 2023-03-29

【中文标题】为啥不将 typelib 嵌入到 COM 服务器中并单独发布呢？

【英文标题】：Why not embed the typelib into the COM server and only ship it separately?为什么不将 typelib 嵌入到 COM 服务器中并单独发布呢？

【发布时间】：2011-07-04 09:25:37

【问题描述】：

我正在分析一个相当老的 COM 服务器项目，以便重用其中的一些东西，并注意到一个奇怪的事情 - 为了将自己暴露给注册表，它实现了一个与 DllRegisterServer() 不同的单独函数，并且该函数接受类型库的路径并从该路径加载类型库，类型库是单独发货的，可以位于任何地方。

典型的解决方案是只使用 ATL CComModule::RegisterServer()，如果它作为资源嵌入，它将很高兴地从同一个 DLL 加载类型库。 DLL 已经使用了 ATL，这应该是最直接的方式。

我试图找出为什么 typelib 没有作为资源嵌入，但看起来这是一个非常古老的设计决定，没有人能解释它。

我可以看到单独发布 typelib 的原因 - 这样 COM 服务器开发人员更容易#import 它。但是为什么不将它作为一个单独的文件发送并作为资源嵌入到 COM 服务器 DLL 中呢？我可以想象 typelib 将 DLL 大小增加了几百千字节，但找不到任何其他严重的原因。

将 typelib 仅作为单独文件提供的原因是什么？

【问题讨论】：

如果组件部署在 COM+/MTS 下，客户端只需注册类型库，标准编组即可工作。

wqw：是的，但是嵌入会有什么伤害呢？

可能是“敏感”代码的情况，任何人都不应该尝试反转......或者只是将密码纯文本存储在 DLL 中:-))

@wqw：这没有任何意义——COM 服务器也已交付，因此无论如何它的二进制代码都是可用的。无论如何，我找到了一个严重的原因 - 它在我下面的答案中。

【参考方案1】：

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