我们有一个 COM 组件项目和一个注册 COM 组件的 Windows 安装项目。我检查了安装项目的先前版本，似乎为 COM 项目中的类生成的 CLSID 总是发生变化，即使有时这些类没有变化。这在某种程度上是我们想要的方式，因为我们希望在同一台机器上保留不同版本的实现。但是，当我手动构建此项目并在同一天多次使用/regfile 选项运行 regasm.exe 时，生成的 reg 文件中的 CLSID 始终相同。它认为在之前的情况下它们发生了变化，这是因为它们是在不同的日子 build 的，但我不确定。那么谁能告诉我这个 CLSID 自动生成的(默认)规则是什么？我认为我们正在使用项目中的默认设置。
我不确定程序集版本是否会影响结果。但我们将程序集版本号指定为 Major.Minor.*，这意味着第三个数字(内部版本号)是自 1.1.2000 以来的天数，第四个数字(修订号)是自午夜以来的秒数除以 2。如果类代码未更改，CLSID 发生更改，则主编号和次编号也相同。因此，如果版本号确实影响 CLSID，我可以看出它不仅仅考虑主版本号和次版本号。
当然，我们没有为这些类分配静态 GUID，否则它不会在我们的安装项目中发生更改。
感谢您的帮助!
最佳答案
是的，如果您没有显式使用 [Guid] 属性，CLR 会自动为接口(interface)和类生成 guid。它做得很好，它包含程序集和类声明的所有部分，这些部分可能会使您的代码二进制文件与以前的版本不兼容。在 COM 中非常重要，这种不兼容性非常难以诊断。
该算法使用完全指定的类型名称以及类型中方法和字段的声明。将它们转换为字符串(“将声明字符串化”)并通过散列将结果字符串转换为 guid。 “完全指定的类型名称”在这里是您的克星，其中包括[AssemblyVersion]。这是完全有道理的，增加程序集版本是一件大事，它会使程序集与使用该程序集的任何代码不兼容。此类代码必须重新编译。 COM 客户端也不异常(exception)。
如上所述，您可以指定自己的 [Guid] 属性来强制 CLSID 为特定值。当您出错并进行重大更改但不重新编译客户端代码时，存在调用 DLL Hell 的风险。失败模式是令人讨厌的、相当随机的 AccessViolation 异常或只是简单地调用错误的方法。执行此操作时，您应该回退到 ComInterfaceType.IsIDispatch，以便客户端代码被迫使用后期绑定(bind)。或者用铁拳控制您的构建和部署过程。
关于com - CLSID自动生成的默认规则是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11758041/