12

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

Community
  • 1
  • 1
Tomislav Markovski
  • 12,331
  • 7
  • 50
  • 72

5 Answers5

9

From the documentation at http://msdn.microsoft.com/en-us/library/system.type.guid.aspx.

The purpose of Type.GUID is 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.

Pieter van Ginkel
  • 29,160
  • 8
  • 71
  • 111
6

Don't use it.

typeof(byte).GUID
00000000-0000-0000-0000-000000000000

typeof(int).GUID
00000000-0000-0000-0000-000000000000

typeof(short).GUID
00000000-0000-0000-0000-000000000000

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.

user703016
  • 37,307
  • 8
  • 87
  • 112
  • Under what conditions? What CLR version? In my case (.NET 4 using LINQpad) I get non-zero results, but different accross program runs. – Ondrej Tucny Dec 29 '11 at 10:33
  • I get non-zeros too (.Net 4, simple console app). – ken2k Dec 29 '11 at 10:34
  • Why I got different GUIDs? How did you get all zeroes? – Cheng Chen Dec 29 '11 at 10:35
  • 3
    And I wanna know why 2 up-votes.. They voted even without a simple test? – Cheng Chen Dec 29 '11 at 10:37
  • I needed to generate a unique ID for the current binary. I tried GUID which worked fine on Windows but gave these 0's on Mono. It was a long time ago but I believe I got around this by simply hashing the application itself to get a unique identifier. It was good enough for my purposes. – WHol Sep 11 '15 at 15:43
2

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 Type instance itself as the key.

ken2k
  • 48,145
  • 10
  • 116
  • 176
1

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.

crypted
  • 10,118
  • 3
  • 39
  • 52
  • 1
    Can you point to a source confirming this? – Oded Dec 29 '11 at 10:25
  • @Oded as long as you dont persist that guids or your metada is subject to change i think its ok .but Type exists single instance thus comparable by reference equiality so better canditate to be dictionary key. i wonder internals of that guid generation too. – TakeMeAsAGuest Mar 19 '19 at 19:37
1

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.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278