http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Doing a bit more digging -- you can also assign a specific GUID to a class or member using the [GuidAttribute] attribute. If you don't specify one, one is automatically assigned. I expect that in this case then, whether it is stable across compilations would depend on the compiler more than anything else. http://ayende.com/3095/system-type-guid-stability#comment5http://ayende.com/3095/system-type-guid-stability#comment5Sat, 12 Jan 2008 12:40:35 GMTYes, it is not a good idea to depend on random values. http://ayende.com/3095/system-type-guid-stability#comment4http://ayende.com/3095/system-type-guid-stability#comment4Sat, 12 Jan 2008 12:36:51 GMTDamn! The version dependency makes it useless. http://ayende.com/3095/system-type-guid-stability#comment3http://ayende.com/3095/system-type-guid-stability#comment3Sat, 12 Jan 2008 12:36:24 GMTBy examining the SSCLI implementation, the GUID is generated from a combination of the full class name (including namespace), the full assembly name (including version or [assembly: ComCompatibleVersion] if present, public key token etc.), and a generic "namespace" signature for all CLR-generated GUIDs. The generation itself is deterministic (it uses an MD5 hash as per the IETF draft document) so the GUID is stable across compilations and runs. (This is true for the SSCLI implementation and not guaranteed to be true for the actual CLR, past, present or future.) http://ayende.com/3095/system-type-guid-stability#comment2http://ayende.com/3095/system-type-guid-stability#comment2Sat, 12 Jan 2008 12:33:03 GMTI'd have thought that if it isn't documented, it's probably best not to rely on it. The best way to uniquely identify the class is to use Type.FullName, or, if you need the assembly information as well, to use Type.AssemblyQualifiedName. http://ayende.com/3095/system-type-guid-stability#comment1http://ayende.com/3095/system-type-guid-stability#comment1Sat, 12 Jan 2008 12:30:12 GMT