Question: Are there any considerations for immutable types regarding hash codes?

Should I generate it once, in the constructor?

How would you make it clear that the hash code is fixed? Should I? If so, is it better to use a property called HashCode, instead of GetHashCode method? Would there be any drawback to it? (Considering both would work, but the property would be recommend).

Answer: 
> 
> Are there any considerations for immutable types regarding hash codes?
> 
> 
> 

Immutable types are the easiest types to hash correctly; most hash code bugs happen when hashing mutable data. The most important thing is that hashing and equality agree; if two instances compare as equal, they should have the same hash code. (The reverse is not necessarily true; two instances that have the same hash need not be equal.)

> 
> Should I generate it once, in the constructor?
> 
> 
> 

That's a performance optimizing technique; by doing so, you trade increased consumption of space (for the storage of the computed value) for a possible decrease in time. I *never* make performance optimizations unless they are driven by realistic, customer-focused performance tests that carefully measure the performance of both options against documented goals. You should do this if your carefully-designed experiments indicate that (1) failure to do so causes you to miss your goal, and (2) doing so causes you to meet your goal.

> 
> How would you make it clear that the hash code is fixed? 
> 
> 
> 

I don't understand the question. A changing hash code is the exception, not the rule. Hash codes are always supposed to be unchanging. If the hash code of an object changes then the object can get "lost" in a hash table, so everyone should assume that hash codes remain stable.

> 
> is it better to use a property called HashCode, instead of GetHashCode method?
> 
> 
> 

What consumer of your object is going to say "well, I could call GetHashCode(), a method guaranteed to be on all objects, but instead I'm going to call this HashCode getter that does exactly the same thing" ? Do you have such a consumer in mind?

If you don't have any consumers of functionality, then don't provide the functionality.
In general, computing the HashCode should be fast. So caching should not be much of an optimization, and not worth the trouble.

If profiling really shows that GethashCode takes a significant amount of time then maybe you should cache it, as a fix. 

But I wouldn't consider it part of the normal practice.