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: 18 | Comments: 63

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.


  1. RavenDB 3.0 New Stable Release - 15 hours from now
  2. Production postmortem: The case of the lying configuration file - about one day from now
  3. Production postmortem: The industry at large - 3 days from now
  4. The insidious cost of allocations - 4 days from now
  5. Buffer allocation strategies: A possible solution - 7 days from now

And 4 more posts are pending...

There are posts all the way to Sep 11, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    31 Aug 2015 - The case of the memory eater and high load
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats