.NET: Is Type.GetHashCode guaranteed to be unique?

Question

I have someone using Type.GetHashCode as if it were a primary key. I think this is a horrible idea but I wanted to know if there was some sort of documented special case that says no two types would have the same hash code.

Answer 1

There are no guarantees around GetHashCode except that it will likely be randomly distributed, not unique. Documentation specifically mentions that:

The default implementation of the GetHashCode method does not guarantee unique return values for different objects. Furthermore, the .NET Framework does not guarantee the default implementation of the GetHashCode method, and the value it returns will be the same between different versions of the .NET Framework. Consequently, the default implementation of this method must not be used as a unique object identifier for hashing purposes. ... if two objects do not compare as equal, the GetHashCode methods for the two object do not have to return different values.

Random distribution is encouraged to avoid hash collisions (slow Dictionaries):

For the best performance, a hash function must generate a random distribution for all input.

It is also a very bad idea to persist results of GetHashCode and base any decisions on this persisted value. The same object may return different hash code on a next application execution:

The GetHashCode method for an object must consistently return the same hash code as long as there is no modification to the object state that determines the return value of the object's Equals method. Note that this is true only for the current execution of an application, and that a different hash code can be returned if the application is run again.

CLR itself changed GetHashCode implementation for a String between .NET 1 and .NET 2 and uses different hash algorithm for 32 and 64 bit versions.

From Guidelines and rules for GetHashCode:

GetHashCode is designed to do only one thing: balance a hash table. Do not use it for anything else.

You should be looking at cryptographic hashes if you want almost unique hashcode based on the object value.

Answer 2

It's not guaranteed to be unique.

If your assemblies are strongly named you could use the fully qualified type name as a unique key to identify a Type.