String.GetHashCode() returns different values

Question

Why is GetHashCode() returning a different value for the same string? I can't describe how to duplicate this, but trust that this is not a practical joke and that the two following lines came from my watch window at two separate times:

"DDD.Events.Application.ApplicationReferenceCreated".GetHashCode() -1386151123 int
"DDD.Events.Application.ApplicationReferenceCreated".GetHashCode() 1858139950 int

How could this happen?

I don't know if this helps, but I am running on .NET 4.0 in VS 2010 and I am debugging an NServiceBus application.

Update:

If you want to know what I ended up doing for this look at this thread: Can you generate an x86 hash value when running in x64 mode?

Corundum

Not only does it return different result when you switch platforms, but for me using .Net 5 on Linux it returns a different result for every single launch. It only stays unchanged while the application is running. – Trumpeter

Answer 1

According to documentation:

If two string objects are equal, the GetHashCode method returns identical values. However, there is not a unique hash code value for each unique string value. Different strings can return the same hash code.

Thus, some other effect must be in play for the two calls to give different results. One theory is that you switched platforms between the calls, from x86 to x64 or vice versa.

Lasser

Yeah, you're right. I've confirmed that by creating a console program and calling Console.WriteLine("DDD.Events.Application.ApplicationReferenceCreated".GetHashCode()). Then I change the platform and run it again. The values returned are the values I mentioned above. – Corundum

I confirm I had the same problem when creating hash code from a unit test and then comparing them in my main application. – Degrease

Documentation for Object.GetHashCode (msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx) says: "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." In other words, don't ever persist hash codes or depend on them being identical from one run to the next. – Ferromagnetism

If you do want a persistent hash code, create a device-independent serialization method (json, XML, protocol buffers, etc.), apply that to your object to get a byte[], and then apply a hash algorithm to that (md5, sha1, etc.). – Pride

+1 The part of the answer after One theory... is the important part of the answer and solved my problem. The other part is obvious! – Ideal

The hash code itself is not guaranteed to be stable. Hash codes for identical strings can differ across .NET implementations, across .NET versions, and across .NET platforms (such as 32-bit and 64-bit) for a single version of .NET. In some cases, they can even differ by application domain. This implies that two subsequent runs of the same program may return different hash codes. learn.microsoft.com/en-us/dotnet/api/… – Dysgenics

Well explained at andrewlock.net/… – Floatation

Answer 2

Is it possible that you copied this string from somewhere?

I had the same problem. I copied the value ans somehow the BOM header is invisible on the first position.

Try checking the length and you see already a difference. Also you could check byte-by-byte.

Patchy

How do I write a good answer? – Audrit