Using ASP.NET 2.0 to Streamline Web Application Development

Microsoft released a curious case study yesterday: “Using ASP.NET 2.0 to Streamline Web Application Development”. (Be aware that if you go to read this document, it is a case study. The document is 100% buzzword complaint and strategically aligned to leverage 80% of your existing infrastructure for a 120% ROI over 2 years).

First, the background section describes the problem Microsoft Human Resource IT was experiencing.

Because of this lack of a standardized architecture and design between applications, HRIT experienced increased costs in application maintenance. For example, HRIT recently spent several thousand dollars over a three-month period to update the privacy statements throughout the HRIT application space. This lack of standardization did not only cost HRIT monetarily, but also in lost productivity.

Reading the problem description you can almost feel the solution jumping out of the page.

The HRIT architecture team determined that it could use the master pages available in ASP.NET 2.0 (described in the "Master Pages" section later in this paper) to create a shell application on which to base all new Web applications in the HRIT application space.

Master pages to the rescue! The description makes the solution sounds as if the master pages are bundled into a Visual Studio Project template. All a developer needs to do is create a new web project with the template, and all the master pages, images, and other common goo appears.

The question is what happens when someone wants to change a master page? A project template is only a starting point and can clone the master page into any number of applications. Since the master pages do not live inside some common area or shared repository, someone needs to apply updated master pages to each application.

Right?

Instead of having to update each individual Web application, HRIT must update only Shell Assemblies to have the legal disclaimer updated on every Web application that is based on Shell Assemblies. The foundation of the shell itself is the master pages available in ASP.NET 2.0.

Here is where the case study lost me. It doesn’t sound as if the solution was a project template as much as a shared class library. I wish the case study went into more detail on how the team built the application, because people are looking for techniques to reuse master pages without resorting to virtual directory tricks. Unfortunately, the study confused and misused a number of technical terms.

My guess is the HRIT solution either uses vdir tricks, or creates an empty master page that is built entirely with code. The code could live in a shared assembly. One of the sticking points with master pages is that the MasterPageFile property of a page requires, well, a file. It would be nice if you could set the master page of a form to a compiled type in a referenced assembly. I can also imagine using the VirtualPathProvider to pull a master page out of a shared assembly's resources, but I'm also pretty sure this would break the designer.