Add custom value in HTML.EnumDropDownListFor

Question

So far I have soemthing like this:

public enum MyEnum
{
    [Display(Name="FirstElement")]
    element1 = 1,
    [Display(Name="SecondElement")]
    element2 = 2
}

And in the view, if I use:

Html.EnumDropDownListFor(x=>x.EnumProperty)

While having:

public MyEnum EnumProperty {get;set;}

On the view model, the dropdown works as expected(I see FirstElement, and the value attached is element1)

The problem is that I want to have a dash in the value, like this:

public enum MyEnum
{
    [Display(Name="FirstElement")]
    element1 = 1,
    [Display(Name="SecondElement")]
    element2 = 2,
    [Display(Name="Third")]
    element-dashed = 3
}

It won't work, as element-dashed is not a valid entry. This won't work either:

[Value("element-dashed")]
[Display(Name="Third")]
elementDashed = 3

Answer 1

The answer to your question is simple. But it warrants an explanation, to explain why this is the answer.

There is no functional reason to want a dash in an enum.

Let's say I have a working application, which contains your enum:

public enum MyEnum
{
    [Display(Name="FirstElement")]
    element1 = 1,
    [Display(Name="SecondElement")]
    element2 = 2
}

Suppose I change the enumerator names:

public enum MyEnum
{
    [Display(Name="FirstElement")]
    BatmanIsBruceWayne = 1,
    [Display(Name="SecondElement")]
    SupermanIsClarkKent = 2
}

I am assuming that every usage of the enum in code is also adjusted accordingly. If you use the Rename method in VS (F2), this is automatically the case.

Nothing has changed about how the application works. Functionally speaking, the name of an enum does not matter.

public enum CardSuit { Hearts, Spades, Diamonds, Clubs }

public enum CardSuit { TheRedOne, TheBlackOne, TheOtherRedOne, TheOtherBlackOne }

Of course, the first one is much more readable for developers than the second one. However, a compiler does not care about the meaning of the enum names. It only cares that the appropriate value is used consistently.

This is the same principle as variable names. While we should of course take care to make variable names readable by developers; there is no technical reason (i.e. to the functionality of the application) why we should use int myDescriptiveInteger over int x.
We only choose a descriptive name for the purposes of readability for humans who maintain the code.

---

There is a single exception to this: If you are calling .ToString() on an enum, in order to have a string representation of the field you are using.

Note: While this is technically possible and has been done before by others; I do wonder if that's really what you should be doing here. You're already assigning explicit int values to the enum values. Those int values are much easier for saving/loading an enum instead of trying to work with its string equivalent. While both are technically possible, using the int is far better due to a smaller footprint and a lack of the naming problem that you are wrongly trying to fix here.

It is not clear from your question whether this is the case for you. Maybe it's done somewhere in your application, maybe it's not. I can't know that without you telling me.

If it is not done, then your problem is functionally irrelevant. The name does not matter except for readability purposes, and I'm quite convinced that your developers won't suddenly stop understanding the intent of the code because there's a dash missing.

If it is done, then you actually have already provided the answer to your problem. Instead of calling .ToString() on the enum; instead you must use the value of [Display(Name="FirstElement")] as the correct "string name" for your enum.

public static string GetName(this myEnum enumValue)
{
    return enumValue.GetType()
                    .GetMember(enumValue.ToString())
                    .GetCustomAttribute<DisplayAttribute>()
                    .GetName();
}

And then you can change the following code:

myEnumValue.ToString();

To the following code, which correctly uses the attribute's value instead of the enum field name:

myEnumValue.GetName();

In both cases, the core answer remains the same: You do not need to worry about the specific name of your enum fields because it is functionally irrelevant.

---

Edit If you want your enum value to be displayed differently in the combobox than you want it to be when you save the value, then use a second attribute to differentiate between the two. But the principle still stands: do not base yourself off of the field names than an enum uses.

And I would like to stress again that you should be using the integer values of your enum. I see no reason why you would explicitly assign int values to your enum and then refuse to use them.