ASP.NET Application Deployment Best Practices – Part 2

In my previous post I started a list of best practices that should be followed for deploying applications to production systems.  This is continuation of that post.

  • Create new Virtual Application in IIS

Right-click [website app will live in] > Create Application

Creating a new application provides each ASP.NET application its own sandbox environment. The benefit to this is that site resources do not get shared between applications. It is a requirement for all new web applications written in ASP.NET.

  • Create a new application pool for Virtual App
    • Right click on Application Pools and select Add Application Pool
    • Define name: “apAppName” - ‘ap’ followed by the Application Name
    • Set Framework version to 2.0
    • Set the Managed Pipeline mode: Most applications should use the default setting

An application pool is a distinct process running on the web server. It segregates processes and system resources in an attempt to prevent errant web applications from allocating all system resources. It also prevents any nasty application crashes from taking the entire website down. It is also necessary for creating distinct security contexts for applications. Setting this up is essential for high availability.

  • Set the memory limit for application pool

There is a finite amount of available resources on the web servers. We do not want any one application to allocate them all. Setting a reasonable max per application lets the core website run comfortably and allows for many applications to run at any given time. If it is a small lightweight application, the max limit could be set lower.

  • Create and appropriately use an app_Offline.htm file

Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)

If this file exists it will automatically stop all traffic into a web application. Aptly named, it is best used when server updates occur that might take the application down for an extended period of time. It should be stylized to conform to the application style. Best practice is to keep the file in the root directory of the application renamed to app_Online.htm, that way it can easily be found if an emergency update were to occur.

  • Don’t use the Default Website instance
    • This should be disabled by default
    • Either create a new website instance or create a Virtual Application under existing website instance

Numerous vulnerabilities in the wild make certain assumptions that the default website instance is used, which creates reasonably predictable attack vectors given that default properties exist. If we disable this instance and create new instances it will mitigate a number of attacks immediately.

  • Create two Build Profiles
    • One for development/testing
    • One for production

Using two build profiles is very handy for managing configuration settings such as connection strings and application keys. It lessens the manageability issues associated with developing web applications remotely. This is not a necessity, though it does make development easier.

  • Don’t use the wwwroot folder to host web apps

Define a root folder for all web applications other than wwwroot

As with the previous comment, there are vulnerabilities that use the default wwwroot folder as an attack vector. A simple mitigation to this is to move the root folders for websites to another location, preferably on a different disk than the Operating System.

These two lists sum up what I believe to be a substantial set of best practices for application deployments.  The intent was not to create a list of best development best practices, or which development model to follow, but as an aid in strictly deployment.  It should be left to you or your department to define development models.