Just wanted to jot down some thoughts and observations before I retire for the evening.  I had the opportunity to spend this last weekend in California working with a good friend of mine on some software.  It was a gruelling set of days, but such is the way and life of a devout coder (or so I hear - maybe I'm just denying myself the good things in life).

The application that we are writing targets the ASP.NET platform.  One of my tasks this last weekend was to take what we had started recently and migrate it to be more of a component rather than written directly into the website.  This was our intention all along but time restraints caused us to reevaluate our immediate priorities and coaxed us down a different path.  Fortunately, we designed it in such a way that facilitated a reengineering.

The goals in 'componentizing' this application were the following:

• Remove it from the existing sample website (test harness) - DONE
• Write it in such a way to support templated layout - IN PROGRESS BUT DEFINITELY SUPPORTED
• Be able to 'plop' it down in an existing website and with very few changes (no recompilation) have the whole product just work - DONE

In (re)writing this, I also had a personal goal of having the component be deployed once to the web server instead of within each virtual directory.  I'd like to support both installing the app once on the web server for all sites/virtual directories to use it (though this implies some common security across the sites - maybe not such a good idea) as well as installing it individually in the site/virtdir that uses it.  Such functionality hearkens back to the good ol' days of the System Registry.  Well, this is best accomplished in .NET with the Global Assembly Cache (GAC).

So here's what I did:

The natural choice in designing the component was to write a Web Server Control that, when compiled, yields a .dll.  Web server controls can be easily integrated within other websites and also offer several advantages over their .ascx (HTML Server Control) counterparts such as client browser detection, a nice clean object model, templated child controls, and much more.  This was exactly the functionality I needed.

A while back I had written a batch file that I use during the project's Post-Build Event.  This batch file copies the newly compiled assembly to a version-specific folder, unregisters it from the GAC if the same version was already registered, and registers it anew.  If you want a copy, just let me know and I'd be happy to send it to you.  It wasn't until I employed this batch file that I realized that it wasn't really well suited for Web Server Controls due to a peculiarity with the ASP.NET worker process.

As it turns out, if your website utilizes a GAC-registered Web Server Control, the worker process (aspnet_wp or w3wp) copies your control dll into a subfolder within WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files at runtime and holds onto it for dear life.  This was manifested by the fact that changes made to the server control were never reflected within the browser.  This basically means that if you want to use a GAC-registered component that is in development, you'll have to kill the ASP.NET worker process after each compilation.  This was incredibly frustrating.  Now if there is an alternative to this, I don't know what it is, but by the same token I haven't looked into it hardly at all.

Needless to say, I reneged on my desires to have it GAC-registered and settled for having it copied into each virtual directory.  This resulted in a much easier and productive development experience.  Who knows, maybe I try to do things the hard way too often.