c# - 什么是 Type.GUID，它与 Type.Equals() 有什么关系？

Question

我在尝试将 System.RuntimeType 的实例与泛型类型 TOut 进行比较时遇到了一些有趣的行为:

Type runtimeT = methodInfo.ReturnType; // get RuntimeType using reflection
Type genericT = typeof(TOut);

// This condition fails because runtimeT doesn't 
// seem to include an assembly qualified name
if(runtimeT.Equals(genericT)) { ... }

这是我的证据:

免责声明:我不知道 GUID 在 CLR/类型系统的上下文中到底是什么，当然除了首字母缩写词代表全局唯一标识符。也许这个名字误导了我。

假设:我在这里假设 Type GUID 唯一标识完全限定类型，包括 AssemblyQualifiedName屏幕截图中的 factoryInfo.ReturnType 缺少它(null 值。)

我的假设错了吗？

• 是类型 GUID 真正代表什么，它是如何使用的？

• 不:为什么不 Equals()通过比较GUID来实现？

Answer 1

进一步扩展 Jared 的(完全正确的)答案:

在 COM 世界中，每个接口(interface)都由一个全局唯一标识符来标识。在 COM 中没有“更改”接口(interface)这样的事情；接口(interface)必须永远相同。相反，您创建一个新界面并为其指定一个新的 GUID。任何两个不同的接口(interface)都需要具有不同的 GUID。接口(interface)相等性在 COM 中定义为 GUID 相等性。

在 .NET 世界中，类型相等性更为复杂。一方面，类型与特定程序集相关联。但不仅如此!如果您加载同一个程序集两次(例如，一次通过其程序集名称，一次通过其磁盘位置)并向这两个程序集询问“相同”类型，您将得到两个不同类型的对象，它们不会比较相等，即使它们显然具有相同的 GUID。

显然这是一个主要的出发点； .NET 和 COM 在这方面非常不兼容。当互操作必须发生时会发生什么？当 COM 和 .NET 在同一进程中运行时，COM 和 .NET 必须就如何比较类型是否相等的一些规则达成一致。 (因为 .NET 正在调用 COM 代码，反之亦然。)

因此，您在 .NET 中可以做的是说“此类型与此 GUID 相关联”。当 COM 规则适用时，COM 代码将通过比较 GUID 来比较两种类型是否相等，因为这就是 COM 世界中相等的含义。

在 .NET 中，使用 .NET 的常用规则比较类型是否相等。

这在常见情况下会带来重大的潜在问题。假设您编写了一个 .NET 程序，它与一个大型、复杂的 COM 库进行互操作。仅选择一个完全非随机的示例，假设您已经为 Word 编写了一个托管扩展，它具有绝对巨大的 COM“表面积”。此表面区域通过主互操作程序集向 .NET 世界公开，其中包含“虚拟”类型，这些类型具有与 COM 世界中相应接口(interface)完全相同的 GUID。然后可以编写 .NET 代码以通过“虚拟”对象与 COM 层通信，这些对象在 COM 中看起来像适当接口(interface)类型的对象，并且在 .NET 代码中看起来是适当 .NET 类型的对象。

这样就可以正常工作了。然后您将 .NET 库发送给客户，您意识到 Word 不会自动将 PIA 发送给客户。相反，您需要运送他们的 PIA。这是巨大的。

因此诞生了 C# 4 的“无 PIA”功能。在 C# 4 中，您可以生成一个 Word 扩展，该扩展仅生成它实际使用的单词 PIA 部分的内部副本。这通常要小得多。然后，您可以重新分发您的扩展库，而无需重新分发大型 PIA。

但这立即出现了一个问题。假设有两个这样的库，并且它们希望在 PIA 中使用两者通用的接口(interface)类型相互通信？从 .NET 的角度来看，类型是针对每个程序集的；从 COM 的角度来看，每个库中的 PIA 类型的副本相同，但从 .NET 的角度来看不同。

因此我们在 v4 CLR 中添加了一项特殊功能。在这种情况下，两个不同程序集中的两种类型(以及 PIA 类型，如果存在的话!)被 CLR 统一并且 被 GUID 视为相等, 匹配 COM 行为。

细节当然比那个简单的草图复杂得多。我的意思很简单，你在这里打开了一个巨大的蠕虫 jar 头； GUID 如何与类型相等交互是一个深刻而棘手的主题，很少有人能完全理解。