Application Block - ASP.NET Website Maintenance

• Download demo - 7.13 KB
• Download source code - 45.4 KB

Introduction

ASP.NET websites would eventually be deployed on a production server. The deployment has been fine tuned to deploy a single page with a single page assembly which has already been incorporated since VS2005. As the application grows, so too the number of web pages. Invariably, bugs or crashes occur. After deployment, there should be ways to gracefully maintain this website.

Background

While there are other crude ways to maintain an ASP.NET website, I felt this needs to be more structured. Considering that an ASP.NET website can span several modules with hundreds of pages, the level of control regarding maintenance should be configurable. Wouldn't it be better if we were able to have control even to the page level?

This article addresses this issue, and is primarily meant for architects, technical leads, and configuration managers who care for graceful maintenance of the Web application.

This article uses an HttpModule to perform this task along with custom web.config configuration settings.

Using the Code

This has to be used only on Live (Production) or Quality Assurance (Testing) environments, and never on a Development environment. This can be easily plugged into an existing application by copying the assemblies Comat.WebSiteWatcher.Business.dll and Comat.WebSiteWatcher.Config.dll present in the attached binary to the bin folder of the web application and making configurable changes to the web.config file.

Website Watcher Module

This is an HttpModule which is loaded to the HttpModule collection of HttpApplication, as depicted in the figure above. This needs to be loaded before redirecting modules like FormsAuthentication etc. We use a HttpModule to prevent unwanted page request processing.

If no redirecting modules are present, add the module as follows:

<httpModules>
    <add type="Comat.WebSiteWatcher.Business.WebSiteWatcherModule, 
              Comat.WebSiteWatcher.Business" name="WebsiteWatcher" />
</httpModules>

If redirecting modules like FormsAuthentication are used, you need to do a workaround. I wish the ASP.NET team could come up with an Add Module at a particular position than at the end.

<httpModules>

    <remove name="FormsAuthentication" />
    <remove name="UrlAuthorization" />

    <add type="Comat.WebSiteWatcher.Business.WebSiteWatcherModule, 
              Comat.WebSiteWatcher.Business" name="WebsiteWatcher" />

    <add name="FormsAuthentication" 
      type="System.Web.Security.FormsAuthenticationModule" />
    <add name="UrlAuthorization" 
      type="System.Web.Security.UrlAuthorizationModule" />

</httpModules>

Configuration Settings

Now that the module is loaded, we need to provide the configuration settings for it in the web.config file.

<comat.webSiteWatcher isUsed="true">
    <webSite isBlocked="false" redirectUrl="~/Maintenance/WebsiteDown.aspx">
        <blockFolders redirectUrl="~/Maintenance/ModuleDown.aspx">
            <!-- block all folders which have this folder combination -->
            <blockFolder>/BlockedFolder/SubFolder/</blockFolder>
            <!-- block only this particular folder -->
            <blockFolder>http://localhost/Security2005/BillManager/</blockFolder>
        </blockFolders>
        <blockPages redirectUrl="~/Maintenance/PageDown.aspx">
            <!-- block all pages in any folder with name Customer.aspx -->
            <blockPage>Customer.aspx</blockPage>
            <!-- block only this particular page -->
            <blockPage>http://localhost/Security2005/Default.aspx</blockPage>
        </blockPages>
    </webSite>
</comat.webSiteWatcher>

The settings are self-explanatory. We have control over whether:

1. to use this HttpModule
2. to bring down the entire website
3. to bring down a module(s) or folder(s)
4. to bring down a web page(s)

The values can either be relative or absolute depending on your need. The example specifying Customer.aspx would block all pages in all folders with Customer.aspx.Tilde ~ paths not supported. If you want absolute paths, specify the full path like http://localhost/Security2005/Default.aspx. The same holds for the folder. High level switches are given for the website so that you can quickly turn it on in case of a major crash, or opt not to use the HttpMododule when not in maintenance mode.

Now that we have specified these settings, we need to be able to read them. To do this, we create our own custom <configSections> node. We need to add this to the top of the <configuration> settings in the web.config file.

<configSections>
    <section name="comat.webSiteWatcher"
      type="Comat.WebSiteWatcher.Config.ModuleConfig,Comat.WebSiteWatcher.Config" />
</configSections>

Maintenance Pages

The redirectUrl attribute points to pages which display a custom maintenance message like Website, Module, or Page is down for maintenance. This needs to be placed in a separate folder and security restrictions removed so requests can be redirected to these pages. In this example, we use forms authentication, and we override these settings by having a web.config in this folder with the following settings:

<system.web>
    <authorization>
        <!-- Allow all users -->
        <allow users="*"/>
    </authorization>
</system.web>

Points to Note

• If performance is a major concern, comment out these three settings in the Web.Config when not in maintenance mode.
• App_Offline.htm is one such file to bring down a website. This is very basic, and does not offer any configuration.
• The <location> node in the web.config can prevent access to a folder without any configuration setting for user specific messages.
• This can also be extended to block sensitive folders like the ASP.NET ISAPI filter does for the App_Code, App_Data etc. folders. Here, we can customize which folder is sensitive and provide a custom message instead of the default page not found message.

History

• 13 Aug. 2007: Initial version.