Type.GUID 是否唯一标识跨编译的每种类型？
我想使用 Type 作为键字典，但我宁愿使用完整类型名称或 Type.GUID。此任务的 Type.GUID 的可靠性和正确性如何？
Ayende Rahien 写道：
你能依赖System.Type.GUID来保持稳定吗？
我所说的稳定是指它将在编译过程中为相同类型生成相同的值。经验证据表明情况确实如此，以下因素决定了类型的 Guid：
- 输入名称（包括命名空间）
- 程序集名称
- 组装公钥
反思系统，原来System.Type.GUID是 最终转化为对System.RuntimeType.GetGUID的调用，这是 直接实现的可怕的InternallCall方法之一 运行时本身。
我想知道...
Possible Duplicate:
Are automatically generated GUIDs for types in .NET consistent?
I want to use Type as a key dictionary, but I'd rather use either full type name or Type.GUID. How reliable and correct is Type.GUID for this task?
Ayende Rahien writes:
Can you rely on System.Type.GUID to be stable?
By stable I mean that it will generate the same value for the same type across compilations. Empirical evidence suggest that this is the case, with the following factors determining the Guid of a type:
- Type name (including the namespace)
- Assembly name
- Assembly public key
Reflectoring into the system, it turns out that System.Type.GUID is
eventually translated to a call to System.RuntimeType.GetGUID, this is
one of the scary InternallCall method that are implemented directly in
the runtime itself.I wonder...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
来自 http://msdn.microsoft.com/en 的文档-us/library/system.type.guid.aspx。
Type.GUID的用途是使用[Guid("...")]获取与该类关联的值。但是，当该属性未关联时，它也会返回一个 guid。问题是它从哪里得到的。小测试表明guid是稳定的。我检查了一个类的 guid，并验证了当我重命名该类时它发生了变化。当我重新命名班级时，我再次得到了原来的指南。然而，由于这些指南是凭空出现的，因此不应相信它们随着时间、版本、框架版本等的变化而保持稳定。From the documentation at http://msdn.microsoft.com/en-us/library/system.type.guid.aspx.
The purpose of
Type.GUIDis to get the value associated with the class using[Guid("...")]. However, it also returns a guid when this attribute is not associated. The problem is where it gets this. A small test shows that the guid is stable. I checked the guid of a class, and verified that it changed when I renamed the class. When I renamed the class back, I got the original guid again. However, since these guids appear out of thin air, they shouldn't be trusted to be stable over time, releases, framework versions, etc.不要使用它。
在 ideone.com 上进行测试，
在各种 ( big) 程序集我找不到两个 GUID 之间的冲突。所以看起来 0-GUID 问题是 Mono 特定的。
Don't use it.
Tested on ideone.com, they run Mono 2.8
EDIT: after using System.Reflection on various (big) assemblies I could not find a collision between two GUIDs. So it seems the 0-GUID issue is Mono-specific.
Type.FullName或 Type.AssemblyQualifiedName 都可以满足您的需求。此外，与 GUID 相比，它会大大简化调试（与未知 GUID 相比，类型名称更有意义）。
另一点是 GUID 属性似乎并不有详细记录，所以我不会依赖它。
编辑：您还可以使用
Type实例本身作为键。Type.FullName or Type.AssemblyQualifiedName are OK for your needs. Also it will simplify debugging a lot compared to GUIDs (meaningful name of type compared to unknown GUID).
Another point is the GUID property doesn't seems to be well documented, so I wouldn't rely on it.
EDIT: you could also use the
Typeinstance itself as the key.我认为使用 Type.GUID 作为字典的键不会产生问题。如果 Guid 不可靠，那么大多数 COM 组件将无法工作。
I think it does not create problem using Type.GUID as a key to your dictionary. if Guid is not reliable than most of the COM component would not have worked.
您应该动态构建字典，每次查找 GUID，或者使用 GuidAttribute 类静态设置 GUID。你永远不应该依赖没有保证的行为。
You should either build the dictionary dynamically, looking up the GUID each time or you should set the GUID statically, with the GuidAttribute class. You should never rely on behavior that's not guaranteed.