+972 52-548-6969
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...
Comments
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.
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.)
Damn!
The version dependency makes it useless.
Yes, it is not a good idea to depend on random values.
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