为什么首先需要 GUID 属性？答案

【问题标题】：Why is GUID attribute needed in the first place?为什么首先需要 GUID 属性？
【发布时间】：2018-05-23 15:53:12
【问题描述】：

GUID 属性的必要性是什么？为什么不让编译器自动处理呢？！

【问题讨论】：

标签： .net com attributes guid

【解决方案1】：

如果编译器自动处理这个问题，你最终会遇到两种情况之一。

每次编译时都会生成一个新的 GUID - 因为应该发布 GUID，所以这会失败。
冲突 - 如果 GUID 每次都相同，则基于（例如）名称的哈希，多个项目最终会出于不同目的使用相同的 GUID。

现有方法 - 显式 GUID 使开发人员能够根据需要控制这些。

【讨论】：

那么总是手动使用该属性是一种“健康习惯”，还是仅在某些情况下才需要？
每次手动使用会好很多——否则，如果 COM 服务器中的接口实现发生了变化，您将不得不重新编译所有客户端事件。
您只需要在有限的情况下添加一个 GUID 属性 - 主要用于 COM 互操作，如果您使用 .NET 编写 COM 对象以供另一个系统使用。根据您的项目类型，这可能是日常活动，也可能是年度活动。

【解决方案2】：

这些属性对 COM 非常重要。它是 .NET 的前身，在 Java 抢尽风头之前在 90 年代达到了鼎盛时期。 .NET 需要与 COM 兼容才能获得成功。或者换句话说，您需要能够用 .NET 语言编写一个大型遗留程序可以使用的 COM 服务器。

[ComVisible] 属性确保 COM 客户端程序可以看到和使用 IEnumerable 接口。必须允许客户端程序枚举 .NET 集合。

[Guid] 属性在 COM 中至关重要，它标识一个接口。这是由 guid 而不是名称完成的，以确保它在不同程序员编写的多个应用程序中是唯一的。 .NET 也有这个，但是使用了一个名称来使人类更容易使用。 “System.Collections.IEnumerable, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”。

IEnumerable，通用版本，没有 [Guid]。泛型与 COM 不兼容。这些天来这并不重要，周围没有太多可见的 COM，其中大部分已经被友好的 .NET 类包装了。但在 Windows 中仍然非常核心，尤其是在全新的 WinRT（又名 Metro，又名 Modern UI，又名 UWP）中。你也不直接使用它，这让 COM 有点像 Windows 编程的汇编语言。

【讨论】：

【解决方案3】：

您可以这样做（只需省略该属性），但即使界面没有更改，编译器也会在每次重新编译时生成一个新的 GUID。这很不幸，因为该界面的用户不知道更改，并且将通过其旧 GUID 检索该界面，因此无法检索它。

【讨论】：

【解决方案4】：

有时您希望为某些类或模块提供一个唯一标识符，该标识符在您的源代码中是恒定的且硬编码的。

【讨论】：

【解决方案5】：

要阅读此定义，您需要查找每个属性的含义。第一个 ComVisibleAttribute 是这样描述的：

控制单个托管类型或成员或程序集中所有类型对 COM 的可访问性。

这告诉我们ComVisible 与 COM 有关，并让我们指定特定类型是否对 COM 程序可见。页面下方是一个链接，指向有关该属性的用途以及类型库导出器如何使用它的更多详细信息。

第二个，GuidAttribute，起初的帮助不大：

当不需要自动 GUID 时提供显式 System.Guid

但同样，您必须阅读其余部分，您会看到另一个提到类型库导出器的内容。

将这两个放在一起，很明显这两个属性控制IEnumerator 在导出到类型库时的处理方式。如果您不知道什么是类型库，那么这对您来说可能意义不大。如果您不使用 COM 互操作，则可以放心地忽略这些属性。如果您正在使用 COM 互操作，则需要知道 Guid 才能从非托管 COM 代码正确访问接口。

Microsoft 将这些放在每个接口定义中，以备不时之需；阅读 MSDN 页面的部分技能是识别此类信息并知道何时对您没有任何用处。既然您知道这两个属性的用途，您应该能够确定它们是否与您相关，否则忽略它们。

【讨论】：