As a lazy developer I have come to rely heavily on ASP.NET’s Just-In-Time compilation model to catch my typos and mistakes. Sometimes it is easier to refresh the browser and let the ASP.NET engine report the location of a compile error than to eyeball each line of code and ensure a clean execution every time. This becomes especially apparent after the ninth or tenth hour of a long tiring day.

Today I’ve been battling a seemingly random error that would not react to source code changes properly. That is to say, I would make a source code change and not only would the expected behaviour not manifest, but the original behaviour would not disappear. I at least expected to see a different runtime error, not exactly the same one.

After scratching my head for twenty minutes, completely restarting my machine and scratching my head for a further twenty minutes I decided to take a step back and see what was actually going on.

It turns out it was a simple, obvious and down-right embarrassing mistake. I have a solution that usually contains a single project. However today I have added a second existing project to my solution. The second project implements an assembly that is not in the GAC and that the main project is dependent upon. I was making changes to the Assembly source code.

Hitting F5 in Firefox triggers a JIT compile on the server for the project hosting the website but does not chain to the Assembly source code. In hindsight this is totally obvious. After all I am hitting the web project not the solution.

The moral of my story? If you rely on a compiler to check your source code don’t get too complacent.

Advertisements