Using ASP.NET 2.0 to Streamline Web Application Development

Friday, March 17, 2006

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.


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.

Scott Friday, March 17, 2006
See, the first thing I thought of was "grep for the text, and do a find/replace with the new text. Maybe wrap it in a nifty gui app or something." Sure it'll take a while in a large system. But how long did it take to implement the master page?
Jon Galloway Saturday, March 18, 2006
LazyCoder Scott -
A grep replace is maybe easier in theory, but in reality probably a lot more work. The problem is that you're changing hundreds or potentially thousands of files. That means you've got to deal with getting them into source control (including getting access to locked files, merging where necessary, etc.). Then you've got the problem with potential misspellings causing your find / replace not to replace everything - this isn't an issue with a master page, which enforces standardization through only storing the data once. Finally, you've got the testing requirements of changing hundreds or thousands of files, since changing code (including ASPX or ASCX) can break both functionality and display.

Having done this both ways, I know which one sounds like less work to me.
Simon Tuesday, March 28, 2006
Have you considered just using a source control package to share the master page source files? Not ideal, I know, but at least its better than copy/paste/grep/etc.

Last point - could a master page be compiled into a different assembly to the page that uses it due to the new ASP.NET 2.0 compilation model? If so, that means at runtime it is indeed using a master page from another assembly... Does this help us reuse master pages in any way? Just a thought - might look into it when I've got 5 minutes.
scott Tuesday, March 28, 2006
Simon: That is a good approach. The source control system can shadow the master page into more than one project. Any check-in would be reflected in all the web apps.

I think the only difficulty that people screech about in that scenario is the need to deploy all the web apps to see the updated master page. I personally don't find that to be a problem, as the deployments should be automated.
Jonathan Minond Monday, April 3, 2006
You can cause Masters to be shared in applications on the same server, using NTFS junction points. You can do the same for User Controls if you dont want them as server controls. This only works if you have permission to create junctions on the server, but if you do, basically you have a direct path to your master folder from any app you want, and the app will think its a local file. This might fall into you "virtual directory" trick though.
Scott Monday, April 3, 2006

Junction points are a cool trick. I think it does fall into a vdir type of trick.
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!