Windows 为什么不将typelib嵌入到COM服务器中，并且只单独发送呢？

我正在分析一个相当旧的COM服务器项目，以便重用其中的一些内容，并注意到一件奇怪的事情——为了将自身暴露给注册表，它实现了一个不同于DllRegisterServer的单独函数，该函数接受到typelib的路径，并从该路径加载typelib，typelib单独发布而且可以在任何地方找到

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

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

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

---

为什么只将typelib作为单独的文件发送？

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

如果组件部署在COM+/MTS下，客户端只需注册typelib，即可进行标准封送处理。wqw：是的，但嵌入会有什么影响？可能是一种敏感代码的情况，任何人都不应尝试反转。。。或者只是将密码以明文形式存储在DLL中：-@wqw:这没有意义-COM服务器也是附带的，因此其二进制代码仍然可用。无论如何，我发现了一个严重的原因——这在我下面的答案中。