We Keep Coding

How can I get the number of enums as a constant?

From Total number of items defined in an enum, I see I can get the number of enums by using:
Enum.GetNames(typeof(Item.Type)).Length;
Works great!
But, I need this number as a constant number, so that I can use it in Unity's [Range(int, int)] feature.
private const int constEnumCount = Enum.GetNames(typeof(Item.Type)).Length;
The above does not work, because the enum count is not a constant number, so I cannot assign it to a constant variable.
How can I get the number of enums as a constant?

It's not possible to get the number of enums as a const. Enum.GetNames uses reflection to get these things, and that's inherently a runtime operation. Therefore, it can't be known at compile time, which is a requirement for being const.

Unfortunately, this is not possible to do in any meaningful way due to technical limitations:
[Range(int,int)] is an attribute, and all information provided to an attribute has to be a const
The only truly bulletproof way to get the number of values in an enum is to use Enum.GetValues(typeof(MyEnum)).Length or the Enum.GetNames(typeof(MyEnum)).Length, both of which are run time reflection.
However, there are hacks that can sort of work. For example, the value of an enum can be cast to an integer. As long as nobody is explicitly defining values for your enums you can use the last element in your enum kind of like this:
[Range(0,(int)MyEnum.LastValue)]
public void BlahBlahBlah() {}
However, know that as soon as someone adds a new entry to the enum after the one you are using or reorders the elements in the enum, your code will break unpredictably and not behave like you want.
It's sad, but the C# compiler is not smart enough to do simple math in the compiler like Java, C, and C++ compilers. So even the example I gave would only really work if the LastValue wasn't ever used for anything except to mark the last element in the enum. It lowers the complexity of the C# compiler, which also greatly improves the compilation speed for your application. As such, there are some trade-offs that the C# and CLR team took to improve your experience in other places.

Assuming that you need a const because you are trying to specify the values for an Attribute (this one?) then you are out of luck.
Your options are:
Hardcode the count in the attribute declaration or as a const itself and be careful to keep the count in sync with the enum definition
Use PostSharp or some other aspect oriented framework to insert the attribute for you. Have never done this myself but it looks possible (How to inject an attribute using a PostSharp attribute?)
You could probably also finagle some way to so this with T4 templates but that would get excessively kludgy.
Were it me, unless you are talking but hundreds of different set of enumerations, I'd hardcode the length and maybe add an Assert where I needed it.
// WARNING - if you add members update impacted Range attributes
public enum MyEnum
{
foo,
bar,
baz
}
[Range(0, 3)]
class Test
{
public Test()
{
int enumCount = Enum.GetNames(typeof(MyEnum)).Length;
int rangeMax = GetType().GetCustomAttributes(typeof(Range), false).OfType<Range>().First().Max;
Debug.Assert(enumCount == rangeMax);
}
static void Main(string[] args)
{
var test = new Test();
}
}

Super late to the game here but I've always used a nifty hack when using enum defaults (i.e. no custom values).
public enum MyEnum {
foo,
bar,
baz,
count
}
Since enums default to starting with 0, ensuring the last entry is named simply 'count' ensures that the value of count is in fact the number of values in the enum itself.
private const int constEnumCount = (int)MyEnum.count;
Cheers!

You cannot assign/create a const at runtime. That is what you are trying to do. A const has to be fully evaluated at compile time, not runtime.
I am not sure about Unity (and why it requires a const), but I would look for using readonly
private readonly int constEnumCount = Enum.GetNames(typeof(Item.Type)).Length;

In C#, a const is defined as constant, i.e. the value (not the calculation which produced it!) is directly embedded in the compiled assembly.
To stop you from doing something problematic, the compiler does not allow you to assign the result of a calculation to a const. To understand why, imagine it were possible:
A.dll
public enum Foo { A, B }
B.dll
public const NumberOfFoos = Enum.GetNames(typeof(Foo)).Length;
// Compiles to:
B.dll
public const NumberOfFoos = 2;
Now you change A.dll:
A.dll
public enum Foo { A, B, C, D }
B.dll
public const NumberOfFoos = 2; // Oh no!
So you would need to recompile B.dll to get the correct value.
It gets worse: Imagine you had an assembly C.dll, which uses B.NumberOfFoos. The value 2 would be directly embedded in C.dll, so it also would need to be recompiled, after B.dll, in order to get the correct value. Therefore (pit of success), C# does not allow you to do that assignment to a const.

Enum.GetName() As Constant property

I have been working in C# for about 8 months so forgive me if this is dumb...
I have an enum that I will need the string value several times in a class. So I want to use Enum.GetName() to set it to a string variable which is no problem. I just do it like so...
private string MyEnumString = Enum.GetName(typeof(MyEnum), MyEnum.Name);
And it works just fine.
But I tried to protect it a little better because this particular Enum is more important that all the others and it would not be good if I accidentally changed the string value somehow so I tried to make it const like this.
private const string MyEnumString = Enum.GetName(typeof(MyEnum), MyEnum.Name);
To my eyes this seems fine as it should all be known at compile time.
But Visual Studio 2013 Throws an error saying the "Cannot resolve symbol GetName". I know it works when it is not marked "const".
So this leads me with two questions about this?
Why does it loose reference to the GetName enum? (After a bit of research I suspect it is something to do with GetName being a method and not a property of the Enum class but the error message just does not make sense to me)
And Finally is there a way to read the Name of MyEnum.Name to a const string other than what I am doing?

Just make it readonly:
private readonly string MyEnumString = Enum.GetName(typeof(MyEnum), MyEnum.Name);
Then it can't be changed afterwards.
You can't assign the result of calling a method to a constant; C# just doesn't allow it - the compiler would have to be calling that method at compile time, possibly before it was even compiled (and not only would it have to generate the IL, it would have to use the JIT compiler to compile that IL).
Enum.GetName(typeof(MyEnum), MyEnum.Name); is calling a method, so you can't assign the result to a constant.
[EDIT] As Jon Skeet says in a comment above, you can use nameof if using C#6 or later (i.e. VS2015 or later):
private const string MyEnumString = nameof(MyEnum.Name);
nameof works because here you are not calling an arbitrary method, but you are instead using a compiler feature to access the name of a type.

You cannot use result of the method as constant, because method evaluation can occur only at runtime. The value of the constant must be known at compile time. In order for compiler to be able to evaluate that constant, it would need to know the semantics of Enum.GetName and execute it at compile time, which is not possible
You can mark it as static readonly instead. That way it will be set once per type where it is declared and it cannot be changed anymore at runtime.

It may not even be known at run-time:
From MSDN:
If multiple enumeration members have the same underlying value, the GetName method guarantees that it will return the name of one of those enumeration members. However, it does not guarantee that it will always return the name of the same enumeration member.
(emphasis added)
void Main()
{
Console.WriteLine (Enum.GetName(typeof(Test),Test.One));
}
public enum Test
{
Zero,
One,
Two,
Uno = 1,
Dos = 2,
}
I consistently get the output Uno for the program above.
The reason is it not known is because enums are compiled to the underlying value. The call above is essentially compiled to Enum.GetName(typeof(Test), 1). GetName looks for a member with that value to find the name. How it does that is apparently an implementation detail that may not product consistent results.
What you can use for a constant in C#6 and later is nameof:
private const string MyEnumString = nameof(MyEnum.Name);

What's the idea behind allowing private constant to be used as default parameters for public methods?

To my surprise, this one compiles and runs:
class Program
{
static void Main()
{
DoSomething();
}
private const int DefaultValue = 2; // <-- Here, private.
public static void DoSomething(int value = DefaultValue)
{
Console.WriteLine(value);
}
}
The method is public whereas the default value "redirects" to a constant private variable.
My question:
What is/was the idea behind this "concept"?
My understanding (until today) was, that something public can only be used if all other "referenced" elements are also public.
Update:
I just ILSpy-decompiled my class to find:
static class Program
{
private static void Main()
{
Program.DoSomething(2);
}
private const int DefaultValue = 2;
public static void DoSomething(int value = 2)
{
Console.WriteLine(value);
}
}
So if the private constant as a default parameter is being done in e.g. a library, the user of the library still sees the default parameter.

What is/was the idea behind this "concept"?
The idea is that as const value is static and never changes - you can use it as default value for method's optional parameters same as you can use normal values. A quote from MSDN :
Each optional parameter has a default value as part of its definition. If no argument is sent for that parameter, the default value is used. A default value must be one of the following types of expressions:
a constant expression;
an expression of the form new ValType(), where ValType is a value
type, such as an enum or a struct;
an expression of the form default(ValType), where ValType is a value
type.
My understanding (until today) was, that something public can only be
used if all other "referenced" elements are also public
Well technically speaking it's correct. But in your scenario both members are accessible as they are defined in the same class however should const in our case be defined outside of class Program it'd be inaccessible inside class Program.

The name DefaultValue is private, but the number 2 is still the number 2.
Because DefaultValue is private, we cannot access Program.DefaultValue from outside of Program. Presumably we wouldn't particularly want to.
And because we've bothered to define DefaultValue at all, it's presumably something that we do care about when we are working on how Program works.
So when we come to define a default value for DoSomething there's presumably some logical reason why the value we want there happens to be the same as the value DefaultValue.
And as such, it's presumably beneficial to be able to use that constant there, for much the same reasons as we would find constants beneficial anywhere.
And since DefaultValue is just a Program-specific way of saying 2, there's no real reason why we can't.
Of course, the metadata would reflect this as 2 rather than the (meaningless to the outside) DefaultValue, but then that would hold if the const was public anyway (the metadata about default values gives only the value, not whether or not it related to any defined constants).
So there's no downside.
So considering that:
There's an advantage to the implementer.
There's no disadvantage to the user, over just a use of a literal 2.
Preventing it would have to introduce a special rule to be an exception to the rule that defined constants can be used anywhere a constant value from a literal can.
Why not?

When you use const, the compiler replaces all the occurrences of the variable with the actual value ,so your code is the same as this:
public static void DoSomething(int value = 2)

Constant variables are replaced at compile-time, so they never really exist in the produced assembly. So code using a constant is really identical to just using the constant value directly. The benefit is just that you can reuse the constant elsewhere and only need to change it in one location.
Now, since constants are always replaced at compile-time, the effect of making them public or private is also quite simple: It just affects what other type can access it at compile-time. So using a private constant for example can be helpful if you just want to keep that constant to the current type, whereas a public constant can be used across the whole application.

Const String From Settings

I would like to set a const string from Settings.
In case I would like to change in the future the program language, it is quite easy;
Just have to modify the appropriate settings!
When trying this:
private const string constString =
"-&" + Properties.Settings.Default.constStringText;
I get this error:
The property or indexer 'Properties.Settings.Default'
cannot be used in this context because it lacks the get accessor.
Any idea?

Since you intend to use this as the default value for an optional method argument, that is:
public void Foo(string something = constString)
{
//do something
}
This constString must be a compile-time constant. From the MSDN page for "Named and Optional Arguments":
A default value must be one of the following types of expressions:
a constant expression;
an expression of the form new ValType(), where ValType is a value type, such as an enum or a struct;
an expression of the form default(ValType), where ValType is a value type.
As such, there really is no way to read a value from a configuration file at runtime then use it for an optional argument.
One workaround would be to instead declare your constString as a readonly field:
private readonly string constString =
"-&" + Properties.Settings.Default.constStringText;
Then make your optional argument required and create a wrapping overload for your method that doesn't take that parameter. That overload in turn calls the old method with the default value resolved at runtime:
public void Foo(string something) //no longer optional
{
//do something
}
public void Foo()
{
Foo(constString); //calls the other overload with the default value
}

This error is in 99% of cases related to a wrong namespace.
You've probably generated some class in which you are using Properties.Settings.Default
Solution: check namespace in that class file. It must be the same as the name of the tag in App.config (Web.config) where that particular setting is stored.

While Chris Sinclair’s answer (a const member must have value type and be evaluable at compile-time, so use readonly) is correct, I should like to explain these restrictions and answer the implicit question what the compiler message means, albeit with the disappointing remark that seems to be simply an error in the compiler.
The error message
The property or indexer 'Properties.Settings.Default' cannot be used in this context because it lacks the get accessor.
This message suggests that the expression Properties.Settings.Default could be made acceptable by adding a getter (and maybe something else) — as far as I know, that is simply wrong. After all, on the one hand, as the asker assured us1, there was a getter, and on the other, as Chris explains, the reason the expression is invalid is that is not evaluable at compile-time, and never can be, given that it depends on the run-time configuration.
Presumably this message is intended for other situations, and has been used here by mistake.
1 I have also seen this, in MSVS 2013, when a default parameter value referred to a property which did have a getter – but at least it also reported “Default parameter value for '<parname>' must be a compile-time constant”.
The restriction to value types
The restriction of const members and default parameter values to value types (as at the C# 5.0 Language Specification, 2012) appears to be not entirely inevitable, but an understandable consequence of other language design decisions.
A reference type can have a constructor evaluable at compile-time, but this is not supported ; perhaps this is because the language offers no way of indicating that a referenced object is immutable, nor even the concept of immutability of reference type objects. (Remember: an immutable reference to an object need not be a reference to an immutable object!)
Delegate values referring to static methods can also be considered fully determined at compile-time, as would those bound to immutable objects, were that concept supported.
Immutable arrays as constant values sound fairly easy to support.
Constant members¹ and (I believe)² default parameter values are specified to be part of the ‘interface’ of the class, in the sense that their values are to be determined at compile time and hard-coded into generated code using that class.
Resolution of the problem
You can use ( static ) readonly constString instead of const constString, to make clear that while the value will not change, it is not determined until run-time, at class or object initialisation (as in Chris’s answer).
If you want to use the expression as a default value for an optional parameter, it must be a true compile-time constant, leaving you two possibilities:
Declare an overload, as in Chris’s answer, e.g.:
Foo() { Foo(Default); } Foo(string s) { Bar(s); }.
This will often be the simpler solution, but could clutter your code and interface if you have many such parameters and thus many overloads, all with documentation comments.
Use null as a convention for the default, and interpret that in your method:
Foo(string s = null) { Bar(s != null ? s : Default); }.
This obviously only works if null is not a supported parameter to Foo(string) and should definitely be clarified in documentation comments.
Maybe: apply the Optional attribute, as in this question: behaviour of Optional attribute:
Foo([Optional] string s) { Bar(etc.?); } .
I have not used or studied this – the documentation seemed rather sparse – but it seems tricky and to yield no more than default = null, unless perhaps null is a supported argument to Foo(string).
References
¹ Language Specification 5.0 §10.5.2.2 10.5.2.2 Versioning of constants and static readonly fields
² I recall reading this, but have not found it in the Language Specification.

I recently encountered this scenario, and while searching for a solution I stumbled on this page. Based on the example above, I was able to resolve my issue like this:
private static readonly String ConStr
= string.Format("Data Source={0};Initial Catalog={1}; User ID={2}; Password={3};",
Properties.Settings.Default.DataSource,
Properties.Settings.Default.Catalog,
Properties.Settings.Default.UserID,
Properties.Settings.Default.Password);
Just wanted to share.

Local constant initialised to null reference

I have read that C# allows local constants to be initialised to the null reference, for example:
const string MyString = null;
Is there any point in doing so however? What possible uses would this have?

My guess is because null is a valid value that can be assigned to reference types and nullable values types.
I can't see any reason to forbid this.
There might be some far off edge cases where this can be useful, for example with multi targeting and conditional compilation. IE you want to define a constant for one platform but define it as null for another due to missing functionality.
Ex, of possible usefull usage:
#IF (SILVELIGHT)
public const string DefaultName = null;
#ELSE
public const string DefaultName = "Win7";
#ENDIF

Indeed, you can initialize local const strings and readonly reference types to null, even though it seems to be redundant since their default value is null anyway.
However, the fact remains that null is a compile-time constant suitable enough to initialize strings and reference types. Therefore, the compiler would have to go out of its way in order to consider, identify and reject this special case, even though it's still perfectly valid from a language standpoint.
The merits of doing that would be disputable, and it probably wouldn't be worth the effort in the first place.

It could be used if you want to write code without keywords, if that strikes your fancy:
const string UninitializedSetting = null;
if (mySetting == UninitializedSetting)
{
Error("mySetting string not initialized");
}

Choosing to name a value (rather than using an in-place magic constant), using const, and setting to null are more or less orthogonal issues, although I agree that the venn diagram might have a very small area of overlap for the three :)
A case that I can think of is when you have as much or more throw-away data than you do code, but you want to ensure the values don't accidentally get changed while writing or maintaining your code. This situation is fairly common in unit tests:
[Test]
public void CtorNullUserName()
{
const string expectedUserName = null;
var user = new User(expectedUserName);
Assert.AreEqual(expectedUserName, user.Name, "Expected user name to be unchanged from ctor");
}
You could arguably structure such code in a plethora of ways that didn't involve assigning null to a const, but this is still a valid option.
This might also be useful to help resolve method overloading issues:
public class Something
{
public void DoSomething(int? value) { Console.WriteLine("int?"); }
public void DoSomething(string value) { Console.WriteLine("string"); }
}
// ...
new Something().DoSomething(null); // This is ambiguous, and won't compile
const string value = null;
new Something().DoSomething(value); // Not ambiguous

If you use constants, for example, for configuration of your application then why not? The null value can represent a valid state - e.g. that a logger is not installed. Also note that when you declare a local constant, you can initialize it to a value given by global constant (which may be a more interesting scenario).
EDIT: Another question is, what are good situations for using const anyway? For configuration, you'd probably want a configuration file and other variables usually change (unless they are immutable, but then readonly is a better fit...)

Besides the situations already pointed out, it may have to do with a quirk of the C# language. The C# Specification 3.0, section 8.5.2 states:
The type and constant-expression of a local constant declaration must follow the same rules as those of a constant member declaration (§10.4).
And within 10.4 reads as follows:
As described in §7.18, a constant-expression is an expression that can be fully evaluated at compile-time. Since the only way to create a non-null value of a reference-type other than string is to apply the new operator, and since the new operator is not permitted in a constant-expression, the only possible value for constants of reference-types other than string is null.