Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,844

filter by tags archive

System.Type.GUID stability

time to read 1 min | 94 words

Here is an interesting issue. 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...


James McKay

I'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.

Sasha Goldshtein

By 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.)

Ayende Rahien


The version dependency makes it useless.

Ayende Rahien

Yes, it is not a good idea to depend on random values.

James McKay

Doing 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.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats