Question

I got a bit of a surprise today when I changed the value of a publicly-visible constant in a static class and then replaced an old copy of the assembly with the newly-compiled version. The surprise was that the existing program that referenced the assembly didn’t pick up the new value of the constant. That is, I didn’t re-compile the executable but rather just replaced that one assembly.

A full description of my experiment is at How constant is a constant?

I’ll admit to being very surprised by this behavior. I understand what’s going on, but I don’t understand why. Is there a particular technical reason why constants couldn’t be picked up at JIT time rather than compile time? Are there cases where doing that would break things?

Answer 1

Constants are supposed to be constant. For all time. Constants are things like the value of pi, or the number of protons in a lead atom.

If your constant changes, it wasn’t really a constant; use a readonly field instead.

Also see the Framework Design Guidelines, which state:

Use constant fields for constants that will never change. The compiler burns the values of const fields directly into calling code. Therefore const values can never be changed without the risk of breaking compatibility.

Essentially, changing a constant without recompiling everything that depends on it is every bit as broken as changing the signature of a method without recompiling everything that depends on it. The compiler “bakes in” all kinds of assumptions about information about metadata from referenced assemblies when it compiles a dependent assembly. If you make any change, you cannot expect things to simply keep on working.