If we are deploying the release build of an application, you should be testing the release build of the application. While it doesn’t sound like a big deal, subtle errors arising from the compiler optimizations can bite you in production. Here is an example of it.

As I mentioned in a previous post, one of solutions for the access denied issue was to pre-load the assemblies in the Global.asax Application_Start event handler. For preloading a specific assembly (lets call it foo.dll) I did something like this:

MyNamespace.MyClass.Equals(null, null);

Things worked fine in the debug build, but in the release build we were getting Access denied for the foo.dll assembly. It was a little weird because all the other assemblies were getting loaded as network service and they all succeeded. Foo.dll was getting loaded under the identity of the user and was failing. I decompiled the foo.dll using Reflector (can’t say how many times this nifty little tool saved the day) and found that the code was optimized by the compiler to this:

object.Equals(null, null);

It does make sense. In hindsight.

We tested the solution in debug build where there was no optimization and everything worked as expected.

So my advice is – if you are deploying the release build of an application, you should be testing the release build of the application.

P.S. – There was an interesting discussion in the MSDN forums a couple of years ago which displayed a similar problem. I will blog about it later, for a little while it got me real frightened about my understanding of the .net platform.