2

We have a big Enum class for EDI Fields, just to make a short example, the enums are declared like:

[Description("Ebene")]
Ebene,

[Description("Zaehlpunktdaten")]
Zaehlpunktdaten,

[Description("Zaehlpunkt")]
Zaehlpunkt,

. .

Well, the enums works fine when you retrieve them by EDIEnums.Zaehlpunktdaten.ToString(), but in some other projects, it returns a wrong value.

If I add a new one in the beginning will return exactly the next one, in this example, if I just had added Ebene and I want to retrieve Zaehlpunktdaten, it will return me Zaehlpunkt.

We have tried also with =0, =1, =2 etc, and it doesn't work neither. Also with local references.

Any ideas about what is happening?

Marius Bancila
  • 16,053
  • 9
  • 49
  • 91
Nekeniehl
  • 1,633
  • 18
  • 35
  • 12
    It sounds like you've changed the enum without rebuilding all the code that depends on it. That's a bad idea. – Jon Skeet May 14 '14 at 14:49
  • 1
    I guess you have duplicate values in enum. Post full enum definition. – Sriram Sakthivel May 14 '14 at 14:50
  • 3
    Also, don't expect ToString() to return the description attribute's value. – qqbenq May 14 '14 at 14:53
  • If the problem appears in some projects but not others it sounds like the projects exhibiting the bad behavior need to have their references checked and rebuilt. – Maurice Reeves May 14 '14 at 14:54
  • If your app must rely on Enum.ToString result, you're doing something wrong. – Crono May 14 '14 at 14:58
  • @JonSkee, we rebuild all the time, we have the DLL on a public folder in which we have the references for the rest of the projects, but, could be that the projects does not get the references from there and use a copied one, I will take a look on it. – Nekeniehl May 14 '14 at 15:29
  • @SriramSakthivel that was my first attempt, and you're right, but now is clean and the error is still there =( – Nekeniehl May 14 '14 at 15:30
  • @qqbenq Of course, we don't want the description, but for a quickly use we use .ToString() to get the name of the field we want, not the description at all. – Nekeniehl May 14 '14 at 15:31
  • If a clean build still shows the problem, you should be able to provide a short but complete program demonstrating the problem. – Jon Skeet May 14 '14 at 15:31
  • @Crono you're right, it's not a good practice, but we have hundred of fields and it's the only way to type it without errors and so one – Nekeniehl May 14 '14 at 15:31
  • @JonSkeet I did one just to verify this and works fine.. – Nekeniehl May 14 '14 at 15:46
  • Right, so you need to work out the difference between that and the situation which fails. There's no way we can guess at that. – Jon Skeet May 14 '14 at 16:07

1 Answers1

1

Let's say assembly A defines MyEnum. By default, each enum value is implicitly assigned an integer "index", something like this:

public enum MyEnum
{
    X = 1,
    Y = 2,
    Z = 3
}

If the source code in assembly B makes use of MyEnum.Y, that code will be compiled against the value at index 2.

If you now add a new item at the beginning, the indexes will shift:

public enum MyEnum
{
    New = 1,
    X = 2,
    Y = 3,
    Z = 4
}

Assembly B is still refering to the value at index 2, which is now X instead of Y. This is the error you're seeing. This is why adding new enum values is considered a breaking change.

If you expected the enumeration to change, you should have numbered the enum values yourself, instead of using implicit numbering, before compiling assembly B.

You now have two options:

  1. A possible workaround is to add the new value at the end of the enumeration, to avoid shifting the indexes. But this is a sloppy workaround.
  2. Consider numbering the enum values now and rebuild any projects depending on that assembly. It might look like a lot of work, depending on how many projects depend on assembly A, but it'll save you and your co-workers from running into this same issue again in the future.
dcastro
  • 66,540
  • 21
  • 145
  • 155
  • We tried adding the numbers and rebuilding and still not working, but could be that the references are not updated correctly, I have to take a look on this. – Nekeniehl May 14 '14 at 15:50
  • @TareqB. Did you rebuild the project that defines the `enum` **and** any other project that depends on this? – dcastro May 14 '14 at 15:51
  • Finally I did the sloppy workaround, the numbering didn't work at all, but I let it also. Thanks. – Nekeniehl May 20 '14 at 09:09