One reason to prefer readonly to const in C#

First off, let’s talk about what’s going on in the C# compiler when you use const or readonly in your field definitions. The const qualifier can be used with primitive data types, and strings only. When used, the value assigned to a const field is inserted directly in all its references in the generated IL code. This is true about other assemblies too. Other assemblies that refer to that const field are compiled as if they have used directly the value itself. This can be the source of problem that I’m going to talk about soon. Readonly fields are run-time constants. They occupy some place in memory, and references to them are resolved in run-time, as if we have referred to an ordinary variable. Actually they are variables that resemble constants.

Imagine that you have created and released a project to the public. Your project contains several assemblies in the form of .dll files. They make use of some constant value in one of the .dll files, e.g., SomeLibrary.dll stores a constant value in one of its classes, e.g.,

C# – using const

1
2
3
4
5
6

publicclass Options
{
...
publicconstint NetworkTimeout = 2000;
...
}

You realize that the value assigned to NetworkTimeout is less than expected, so you decide to update SomeLibrary.dll files in all your customer machines with a new one in which NetworkTimeout is set to 3000. But it will not work. Because all references to NetworkTimeout in other assemblies have been replaced with the constant 2000, and the new value will not be fetched any more. In this case, the problem will be solved only when all other assemblies are rebuilt. No other update scenarios will do.

But if we have used readonly instead of const, the problem would have been solved with updating SomeLibrary.dll only.