Changing order of enum values in C# breaks binary compatibility badly

Suppose I have a public interface that uses this enum:

public enum LogLevel // v1
{
    Info,
    Warning,
    Error,
    Debug
}

There is a problem with this enum: the values are not in the order of increasing severity. Let’s say we want to fix this like so:

public enum LogLevel // v2
{
    Debug,
    Info,
    Warning,
    Error
}

It will definitely break backward compatibility, because numeric equivalents of the enum values will change. But how much of an effect will it have?

Let’s say, we have an assembly compiled with the new version of the enum:

public class Log
{
    public static void ShowLevel(LogLevel level)
    {
        Console.WriteLine("Log received " + level);
    }
}

and we call it from an assembly compiled with the old version of the enum:

Log.ShowLevel(LogLevel.Error);

If LogLevel.Error is passed as a symbolic constant like in Java, we should be fine. If it is passed as a number like in C, the results won’t be pretty.

The experiment shows, that the result is passed as a number, like in C:

Using enum provider version 2.0
Passing to Log: LogLevel.Error
Log received Warning

See attached code for details: ChangeEnumValue.7z.
Conclusion: do not change the order of enum values in C#, it will break the clients badly.

Leave a Reply

Your email address will not be published. Required fields are marked *