Type.GUID是否在编译中唯一标识每种类型？

Question

  

可能重复：
  Are automatically generated GUIDs for types in .NET consistent?

我想将Type用作关键词典，但我宁愿使用完整类型名称或Type.GUID。 Type.GUID这项任务的可靠性和正确性如何？

Ayende Rahien写道：

  

你能依靠System.Type.GUID稳定吗？

     

稳定我的意思是它将在编译中为相同类型生成相同的值。经验证据表明情况就是如此，以下因素决定了一种类型的指导：

     

  
• 类型名称（包括命名空间）
  
• 程序集名称
  
• 装配公钥
  

     

反映到系统中，事实证明System.Type.GUID是   最终转换为对System.RuntimeType.GetGUID的调用，这是   直接实现的可怕的InternallCall方法之一   运行时本身。

     

我想知道......

Answer 1

来自http://msdn.microsoft.com/en-us/library/system.type.guid.aspx的文档。

Type.GUID的目的是使用[Guid("...")]获取与课程相关联的值。但是，当此属性未关联时，它还会返回一个guid。问题在于它得到了什么。一个小测试显示guid是稳定的。我检查了一个类的guid，并在我重命名该类时验证它已更改。当我重新命名课程时，我再次得到了原始的指导。但是，由于这些指导是凭空出现的，因此随着时间的推移，版本，框架版本等不可信任它们。

Answer 2

不要使用它。

typeof(byte).GUID
00000000-0000-0000-0000-000000000000

typeof(int).GUID
00000000-0000-0000-0000-000000000000

typeof(short).GUID
00000000-0000-0000-0000-000000000000

在ideone.com上测试，他们运行Mono 2.8

编辑：在各种（大）程序集上使用System.Reflection后，我找不到两个GUID之间的冲突。所以似乎 0-GUID问题是Mono特定的。

Answer 3

Type.FullName或Type.AssemblyQualifiedName可以满足您的需求。与GUID相比，它还将简化调试（与未知GUID相比，有意义的类型名称）。

另一点是GUID属性似乎没有很好的记录，所以我不会依赖它。

编辑：您也可以使用Type实例本身作为密钥。

Answer 4

我认为使用Type.GUID作为词典的键不会产生问题。如果Guid不可靠，那么大多数COM组件都无法工作。

Answer 5

您应该动态构建字典，每次查找GUID，或者您应该使用GuidAttribute类静态设置GUID。你永远不应该依赖那些无法保证的行为。