I just wasted few hours of debugging before realizing that contrary to .NET, in .NET Core, GetHashCode returns a different value every time you run your code. I totally understand the rationale for this. Relying on hash code values is a very bad idea (like serializing them). I even remember that internal builds of .NET at Microsoft (prior to Core) would change the behavior of GetHashCode for every build so that nobody gets too comfortable with it.
Having said all this, I’m currently debugging complex code that makes heavy use of GetHashCode. I know the bug is my own doing and has nothing to do with GetHashCode but each time I run it, it fails elsewhere. Very annoying. Is there a way to force GetHashCode to behave like in .NET (while I’m debugging) without having to write my own hash function and having to replace it everywhere in my code?
The pragmatic solution I have found to get string.GetHashCode to return predicable values across multiple executions is simply to switch back to classic .NET (4.6). Since there is nothing .NET Core specific about my code, the only work I had to do was create a new project. I debugged my code under .NET 4.6, fixed the bug and switched back to Core.
According to docs only change of framework should change the hash result. I too stumbled upon this. My solution was to create my own hash algorithm. It just took a few minutes as I didn't need anything fancy.
On a side note I have filed a bug for dotnet core 1.1. (string).GetHashCode() here.
Update
The hash can change due to framework or domain. This means that two subsequent runs of the same program can return different results.
Alas my bug report is moot and changed to a documentation update instead.
Update update
Documentation is updated to be a little bit more clear.