I'll admit - C# isn't my regular language of choice. I don't have anything against it personally; I just am not a big fan of case sensitivity and semi-colons. But I never found it truly annoying until today.
As mentioned previously, I'm using the Pivotal web services generator for a way my app to talk to Pivotal. The web services generator creates C# source code, which is fine. Unfortunately, we discovered this issue with the IDs for certain Pivotal objects being hard-coded into the generated code. This is no big deal if you are generating web services for fun or from production, but usually it is preferable to use the same compiled code across development, test and production, and this prevents this approach.
Since I don't expect these web services to change much, I thought an okay workaround would be to modify the generated code to read the IDs from a config file. That way, when we move from test to production, we can just change the IDs. Sounds reasonable, right?
I wanted to make the changes to the generated code in an automated fashion so that if we regenerated, I could just re-run my updates and be good to go. I really only had to change a few places, but this was the one that bit me:
Contact_for_Order data1 = new Contact_for_Order();
I thought I could just change the "case" line to use a variable. No can do. This is because while switch....case is similar to select case in VB.NET, it has one important difference: it requires that the case items be constants or enums - variables are not permitted. I read a number of explanations about why it works this way, including those of several people who believe this is superior. Bully for them, but in my situation it really wasn't very helpful. (Apparently I'm not the only person who has been frustrated by this.)
At any rate, the solution was for me to also change the switch...case to an If...then statement. (My code only contained one case item anyway, so it isn't the end of the world.) A bit more work, but not a deal breaker.