Messing with JIT options

Sometimes different problems come together to provide a unified solution. Today I think I stumbled across such a thing.  Earlier today I noticed a comment post to an old blog entry of mine about how to tell if an assembly is a debug or release build.   It was nice to see that Google and my blogged helped out a fellow MVP, Doug Holland . 
Then tonight I was chatting with another fellow MVP who was having troubles with a C# build, over what looked like another case of over optimization by the JIT.  I thought it sounded very similar to the issue I posted about String.IsNullOrEmpty causing a runtime null exception.  MVP2 asked if there was a way around the JIT optimizations.  Well there is the compiler options in both VB and C#, but that switch alone does not stop these kind of over optimizations.  You could of course just do a debug build but that would mean you need to remove any Debug.Asserts or Prints you might have in your code.
But putting these two seemingly different things together, gives you the option to turn on JIT tracking using the Debuggable attribute, as well as turning off optimizations.

<Assembly: Debuggable(True, True)>
This will fix the null reference issue, and may help you if you encounter weird runtime bugs only in a release build, not a debug build.  Of course it does mean your code might not run as fast as it otherwise would.

Update: Well it turns out this fixes the null reference issue, but not the fix the issues that Maurice reported.