const
implies static
(you don't need an instance to reference the const
value).
I want to also add this important point: When you link against (reference) an assembly with a public const
, that value is copied into your assembly. So if the const
value in the referenced assembly changes, your assembly will still have the originally compiled-in value.
If this behavior is not acceptable, then you should consider making the field a public static readonly
field.
Lib.dll, provided as binary:
public class Foo {
public const int HATS = 42;
public static readonly int GLOVES = 33;
}
App.exe, references Lib.dll:
Foo.HATS // This will always be 42 even if the value in Lib.dll changes,
// unless App.exe is recompiled.
Foo.GLOVES // This will always be the same as Foo.GLOVES in Lib.dll
From MSDN:
Don’t create a constant to represent information that you expect to change at any time. For example, don’t use a constant field to store the price of a service, a product version number, or the brand name of a company. These values can change over time, and because compilers propagate constants, other code compiled with your libraries will have to be recompiled to see the changes.
From DotNetPerls:
DLLs. When you use a const
field or declaration, the C# compiler actually embeds the const
variable's value directly in the IL code. Therefore, it essentially erases the const
as a separate entity.
Caution:
If programs that depend on a const
are not recompiled after the const
value changes, they may break [because they'll continue to use the previous value].
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…