Disabling the <httpRuntime> approach provides no feedback to the end user. Fortunately, there is a cool feature available in ASP.NET 2.0 for taking the application offline - the App_Offline.htm file. If we place a file called App_Offline.htm in the root of the website, all requests to this site will now return the content of this html-file. We can place any static content in this file. It will cause the application domain to recycle. The same will happen when we remove the file. The application domain will also recycle if we edit the file, in the same way that an application will recycle when we edit web.config

The main advantage of App_Offline.htm over <httpRuntime> is that with App_Offline.htm, the content of the App_Offline.htm file is returned to the client. So we can place a rich App_Offline.htm file with a combination of both text and graphics explaining why the website is unavailable. There are some points that we should keep in mind. First, the ASP.NET runtime will not return an App_Offline.htm file if it exceeds 1 MB in size. Moreover, if our App_Offline.htm file is too small (less than 512 bytes), Internet Explorer will display its "Friendly Http Errors" (this can be configured in the Tools->Internet Options->Advanced tab within IE, and is on by default with IE6) rather than the content returned by App_Offline. So developers should ensure the App_Offline.htm is at least 512 bytes long.

That means that users are basically locked out of the application and we are free to make any changes.

Figure 3

If we look at the address bar in the abovementioned screen shot, we will see that we did not actually request app_offline.htm. We requested the application's WebForm1.aspx page and were sent the contents of the app_offline.htm file instead.

The usage scenario for this is for site maintenance and it can be easily included as part of a deployment script, where this is the first file added and the last file deleted during the deployment.

It should be noted that we should remove the App_offline.htm file after we are finished copying the files. Once removed, the next incoming request will bring the ASP.NET 2.0 web application back online.

Lastly, we can write our own custom code in order to show the user a proper message instead of an error page. Readers can see my articles named “Working with Custom Error Pages Using ASP.NET.”