Creating a constant Dictionary in C
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In C#, developers often ask for a "constant dictionary" when what they really need is a dictionary whose contents cannot be changed after initialization. That distinction matters because const in C# only works for compile-time constants such as numbers and strings. A dictionary is an object created at runtime, so the right solution is immutability, not const.
Why const Does Not Work
The const keyword is limited to values the compiler can embed directly into the assembly. A Dictionary<TKey, TValue> is allocated at runtime, so this will not compile:
That means the real design question is how much protection you need:
- prevent reassignment of the dictionary reference
- prevent callers from mutating entries
- guarantee true immutability for shared application state
Each goal has a slightly different implementation.
static readonly Prevents Reassignment
The simplest pattern is static readonly:
This prevents the Values field from being assigned to a different dictionary after type initialization. However, the dictionary itself is still mutable:
So static readonly protects the reference, not the contents. That is good enough for private fields that only trusted code can reach, but it is not enough for a public API.
ReadOnlyDictionary Protects the Public Surface
If you want callers to read entries without changing them, wrap the mutable dictionary in ReadOnlyDictionary.
Callers can read values:
But attempts to add or remove items through Values will fail.
This is usually a solid choice for application configuration tables, lookup maps, and public constants exposed by a library.
ImmutableDictionary Gives Stronger Guarantees
If you want true immutability, use ImmutableDictionary from System.Collections.Immutable. Unlike ReadOnlyDictionary, there is no hidden mutable dictionary behind the wrapper.
If you need a modified version, the API returns a new dictionary rather than changing the old one:
That behavior is especially helpful in concurrent code and in systems where shared state must stay predictable.
Which Option Should You Choose?
Use static readonly Dictionary when the dictionary is internal and only trusted code can access it.
Use ReadOnlyDictionary when you want a simple public read-only view but are comfortable keeping a private mutable backing store.
Use ImmutableDictionary when you want the strongest guarantee that values cannot be changed accidentally.
A practical pattern for many codebases is to keep the implementation simple and return IReadOnlyDictionary<TKey, TValue> from APIs:
This keeps your interface flexible while preserving safe behavior.
Common Pitfalls
The biggest mistake is assuming readonly means the contents cannot change. It does not. It only means the field cannot point to a different object after initialization.
Another mistake is exposing a mutable Dictionary publicly and trusting callers not to modify it. That creates hidden coupling and makes debugging harder.
Developers also sometimes use ReadOnlyDictionary and forget that the backing dictionary can still change internally. If some other code keeps a reference to the original dictionary, the "read-only" view will reflect those mutations.
Finally, avoid overusing const terminology when discussing collection types. In C#, collections are runtime objects, so immutability is the concept that actually applies.
Summary
- You cannot declare a
Dictionaryasconstin C#. - '
static readonlyprevents reassignment but not mutation of entries.' - '
ReadOnlyDictionaryexposes a safer public read-only wrapper.' - '
ImmutableDictionaryprovides true immutable collection behavior.' - Pick the option that matches your API and mutation requirements.

