Suppose I have a public interface that uses this enum:<\/p>\n
public enum LogLevel \/\/ v1\n{\n Info,\n Warning,\n Error,\n Debug\n}\n<\/code><\/pre>\nThere 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:<\/p>\n
public enum LogLevel \/\/ v2\n{\n Debug,\n Info,\n Warning,\n Error\n}\n<\/code><\/pre>\nIt will definitely break backward compatibility, because numeric equivalents of the enum values will change. But how much of an effect will it have?<\/p>\n
Let’s say, we have an assembly compiled with the new version of the enum:<\/p>\n
public class Log\n{\n public static void ShowLevel(LogLevel level)\n {\n Console.WriteLine(\"Log received \" + level);\n }\n}\n<\/code><\/pre>\nand we call it from an assembly compiled with the old version of the enum:<\/p>\n
Log.ShowLevel(LogLevel.Error);<\/code><\/p>\nIf LogLevel.Error<\/code> 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.<\/p>\nThe experiment shows, that the result is passed as a number, like in C:<\/p>\n
Using enum provider version 2.0
\nPassing to Log: LogLevel.Error
\nLog received Warning<\/code><\/p>\nSee attached code for details: ChangeEnumValue.7z<\/a>.
\nConclusion: do not change the order of enum values in C#, it will break the clients badly<\/font><\/b>.<\/p>\n","protected":false},"excerpt":{"rendered":"