I’ve been working  a bit on the .NET 2.0 version of the West Wind Web Store over the last few days after Miguel Castro pointed out that – uh, the version I’ve been sending people hadn’t been updated for the release version of VS.NET. In my mad rush getting things online here after the .NET 2.0 release and updating a variety of tools I completely spaced that the core codebase for the shipping product hadn’t been updated to the release. Most of the stuff is very minor, but out of the box the code won’t compile.

Anyway – while I was at it I went through and updated a few features in the base Web application and databinding classes that I’ve been meaning to address for some time as well as fixing a couple of annoying little intermittent bugs related to cookies dealing with logins (thanks Miguel ).

Anyway, today I ran through a number of deploys to the live Web site. And well, it didn’t go so well. I’ve been using the new Web Deployment Projects tool – or rather the ASPNET_MERGE.EXE utility contained within it – in combination with my compiler utility. The jist of these tools in any format are to give you a more compact compiled Web application and it works pretty well for what it’s designed to do.

However, even though this tool can pack down the massive number of files that the ASP.NET compiler creates into just a few files there are still a lot of files you need to remember to deploy: The binary DLLs, a few .Compiled files (also in bin) and then depending on your configuration the actual ASPX/ASCX/ASMX etc. files that you need in your directories.

Ultimately I never do a full deploy to the Web site – I usually just update the bin directory files plus any changed ASPX pages. I still use the ‘old’ deployment scenario where the ASPX pages contain the page script, because no matter what you have to distribute these files even in the ‘code less’ deployment as they act as a placeholder (required for security only though).

Long story short, there are a still a lot of files that get shuffled back and forth especially if it’s been a while since the last upload of a site. Somewhere while working on my project I decided to rename my assembly for the Web dll. When I uploaded to the server I copied the new assembly along with the other support assemblies. No problemo right?

Well, problemo! I didn’t delete the old assembly! So now I had wwStore.dll and WestWind.WebStore.dll both of which basically contain the same classes. Quick, which one does ASP.NET load? Answer: Both…

If you do this in development mode this isn’t much of a problem. However, in a deployed application this error is fatal – to the point of not firing Application_Error. Understandably – my app is doing stuff in Application_Error inside of global.asax that’s not going to work if the assemblies can’t resolve properly. But the problem is that I ended up getting nothing more than a blank screen for my app. No error, no message, no hint that anything is wrong, no nothing. After a brief freak-out, it took a while to figure out how to work around this.

My deployed apps always enable a generic error handler that fires into Application_error. I can disable this optionally with a flag in web.config which essentially bypasses all the custom error handling and simply let’s ASP.NET handle the error.  Once I did that I did get the ‘yellow screen of death’ from ASP.NET which alerted me to the problem of the duplicate DLLs.

But it sure would be nice if ASP.NET could have a last chance fail-safe mechanism to display some sort of error message or Hey I’m still alive message instead of a completely blank page. Like some sort of wrapper around the Application_Error event handler to ensure that SOMETHING gets displayed if there’s an exception in that code. No error of any sort is a little drastic…

But the real moral of the story is when updating your BIN directory, ALWAYS delete all of the files before copying files into the directory unless you’re absolutely sure you’re overwriting all existing files. Otherwise you might end up with junk in the directory that can end up causing all sorts of weird behavior.

Why am I writing this up - it certainly isn't a common scenario, but heck it's the second time I've run into this now, and each time I've spent a frantic few minutes trying to figure out how to get the app back up and running.