I found this great article about switch statements in c# (really any CLS language.)  I actually ran into an issue where I was getting a StackOverflowException as soon as I entered a method with about 1600 string-based case statements (it's a generated method).  It looks like I was bumping my head the local variables limit in .Net 1.1.  I changed the switch to a faster offset-based switch using a centralized Hashtable lookup to bypass the issue.

Actually, I found the problem using Reflector and examining the MSIL first.  Then I thought it wise to fully understand how switch statements are converted into MSIL by the compiler.

At work I am one of the ~4 code reviewers on the team.  In this position, I come across code that makes me scratch my head from time to time.  For one reason or another a developer chooses interesting logic (I've done it plenty of times too, I still do; nobody's perfect.)

Today, I came across this in a custom UserControl:

public override Visible {
   get { return base.Visible; }
   set { base.Visible = value; }
}

This is such an illustration of a fundamental lack of understanding that it's almost elegant.  In this case, it was probably due to a very tight schedule and happened to get overlooked.

If you can't spot the WTF, and you're a developer, you should get yourself one of those "Learn to Program in 21 Days" books.  You'll also want to consider crying yourself to sleep.

I've been working with Windows Workflow Foundation recently and came across a weird exception that was reported by one of my colleagues.  It turns out that if create a Delay Activity with a timeout value that exceeds 2^32-2 milliseconds, you will generate an exception.  This ends up being about 46 days (49.7 exactly, I believe.)

When the issue was reported, I couldn't reproduce it with my test harness.  So I set out to search the Internet for more information.  Unfortunately, it seems that Windows Workflow Foundation is not widely used (yet?) making the task a bit more difficult.  With a few choice Google queries, I was eventually able to come across the issue as reported to Microsoft here.

There's apparently a bug in the Thread Timer that results in this limitation.  The exception is:

System.ArgumentOutOfRangeException: Time-out interval must be less than 2^32-2.

Once I confirmed that this was actually an issue, I set out to, again, search the internet for a fix.  I came across a few articles that mention that the issue was repaired in the .Net 3.5 Fx, but I couldn't tell a client, who's in production, to update their entire framework.

I decided to setup a sandbox and try to reproduce the issue in my local environment and was still unable.  The good news is that I was running 3.0, so something in my environment had fixed the issue.  After an hour or so, I realized that I was assuming the the issue was reported from an environment with the latest service packs (silly me.)  Once I removed that assumuption, along with 3.0 SP1 from my environment, I could reproduce the issue.

Once I was able to reproduce the issue, then reinstall SP1 to see the issue was fixed, I could confidently report that this issue was fixed in .Net 3.0 SP1 and the client needn't upgrade to 3.5; they just needed to install the service pack.

I decided to write this up in case anyone else came across the issue.  When you're dealing with an expensive, deployed product, you have to be able to justify any changes to the software stack.  And, since Microsoft does have any change log or fix history for their service pack (beyond a simple "hey we fixed some issues with Workflow), I thought it'd be helpful to someone else in a locked down environment to have third-party confirmation that SP1 is all that's needed.

Also, I find it interesting that Microsoft's Workflow team didn't set any delay activities with large timeouts prior to releasing the framework.  Never assume anything..