不同类的重复 ProgId 的可能后果答案

【问题标题】：Possible consequences of duplicate ProgId for different classes不同类的重复 ProgId 的可能后果
【发布时间】：2015-08-19 11:03:38
【问题描述】：

在我维护的软件中，我观察到 COM 类 标有相同的 [ProgId]s。

AFAIK ProgId 是组件的人类可读标识符，它应该与组件的 CLSID 一对一映射。

所以我想知道：

是否有充分的理由为不同的类设置相同的 ProgId？
可能的后果是什么？（除非无法使用这种方便的方式访问组件）

提前致谢。

【问题讨论】：

你应该阅读this MSDN topic。重要部分：ProgIDs are automatically generated for a class by combining the namespace with the type name, 和 ProgIDs are limited to 39 characters and can contain no punctuation other than a period。
@EBrown 在我的情况下，所有 ProgId 都使用此属性显式设置为相同的值。该值是应用程序的名称。（也许开发人员认为“ProgId”是“程序标识符”所以项目/应用程序的名称......）

标签： c# .net windows com

【解决方案1】：

ProgId 为 coclass 的 CLSID guid 提供友好名称。对脚本语言很重要，没有很好的方法来了解 guid。也被支持后期绑定的语言使用，如 VB.NET 和 C#。从字符串到 guid 的转换发生在运行时。工厂函数的通常名称是 CreateObject()，语言运行时通过查看存储在 HKLM\Software\Classes 中的注册表项来实现它。

复制它们时会出现什么问题的提示。客户端程序创建的实际对象是随机的。无论哪一个碰巧最后注册。客户端程序调用了与它打算调用的方法完全不同的方法。这可能会触发 DISP_E_Xxxx 错误返回，但这当然不能保证。总的来说，这是一个非常令人讨厌且无法调试的事故。

唯一不会出现此问题的方法是客户端代码使用早期绑定并使用类型库来了解 guid。这并不罕见，但它不在您的控制范围内。如果您知道客户端代码不使用它们，那么只需省略 [ProgId] 属性，这样就不会发生意外。

【讨论】：

感谢您的完整回答汉斯。最后一部分解释了为什么一切都按预期工作而没有任何明显后果：COM 类仅用于从 VBA 到 TLB。