How to stop C# from replacing const variable with their values?

We have a project that's compiled into a DLL called consts.dll that contains something like:

public static class Consts
{
    public const string a = "a";
    public const string b = "b";
    public const string c = "c";
}

We have multiple projects of this sort, each compiled into a DLL of the same name (consts.dll) and we replace them according to need. We have another class that uses these consts:

public class ConstsUser 
{
    string f() { return Consts.a; }
}

Unfortunately, Consts.a is optimized to "a" , so even if we replace Consts.dll implementation, we still get "a" instead of the correct value and we need to recompile ConstsUser. Is there anyway to stop the optimizer from replacing const variables with their values?

I think usage of static readonly modifiers fits your needs:

public static class Consts
{
    public static readonly string a = "a";
    public static readonly string b = "b";
    public static readonly string c = "c";
}

Constants are hard-coded on the call-site, so that is your problem. Static readonly variable can be modified only in variable declaration or static constructor of Consts class, and it will not be inlined on the call-site.

From the book CLR via c#

> When code refers to a constant symbol, compilers look up the symbol in > the metadata of the assembly that defines the constant, extract the > constant’s value, and embed the value in the emitted Intermediate > Language (IL) code. Because a constant’s value is embedded directly in > code, constants don’t require any memory to be allocated for them at > runtime. In addition, you can’t get the address of a constant and you > can’t pass a constant by reference. These constraints also mean that > constants don’t have a good cross-assembly versioning story, so you > should use them only when you know that the value of a symbol will > never change.

As we can see, using const does have its benefits when we know that the value of a symbol will never change. It can perform faster because the CLR does not need to resolve the value.

> In fact, after building the application assembly, the DLL assembly > isn’t even loaded at runtime and can be deleted from the disk because > the compiler does not even add a reference to the DLL assembly in the > application's metadata.

As already suggested by @Sergey Berezovskiy, we could use static readonly if you need the CLR to resolve the value dynamically at runtime. Performance is affected with this solution, but there is also another benefit.

> In addition, a field can be of any data type, so you don’t have to > restrict yourself to your compiler’s built-in primitive types (as you > do for constants).