Developing Dane

Update 10/2016 - This posting is better viewed in my new blog . This is part 2 of my previous  That pesky enum post.  You should read part 1 first.  In part 1 I defined the enum Beers and a static class BeersMockEnum and illustrated their use. Now, I make modifications to these types by inserting a new item (Bitter) in the Beers enum and the BeersMockEnum class as follows. public enum Beers { IPA = 0, Bitter, Lager, Porter, Stout } public static class BeersMockEnum { public static int IPA { get { return 0; } } public static int Bitter { get { return 1; } } public static int Lager { get { return 2; } } public static int Porter { get { return 3; } } public static int Stout { get { return 4; } } } I then recompile only the ClassLibrary project (which holds these definitions) and deploy the newly compiled assembly to the run directory replacing the existing ClassLibrary.dll but not the existing ConsoleApplic

Update 10/2016 - This posting is better viewed in my new blog . The .NET enum, such a simple concept.  At the most basic level an enum is a collection of key/value pairs with a restricted string key and an integer value. However, the enum can trick you.  It would seem logical that when you define a new enum it'd obey the same rules as would any class you define.  That assumption can lead to subtle and sometimes difficult to identify issues. To illustrate the point I'd like to make I'm going to define a new enum called Beers and then define a new class called BeersMockEnum who's purpose will be to mock the behavior of the Beers enum.  Utilizing these I'll illustrate how they differ in a way that can present significant problems in real life implementation and deployment scenarios. First I'll define the Beers enum. public enum Beers { IPA = 0, Lager, Porter, Stout } Using the following I'll iterate over the values and output.