Tips for Deploying ASP.Net Application in Production

One of my previous article Deploying ASP.Net Applications discussed about how to deploy asp.net applications in IIS. In this article, we will see some of useful tips that can help us in deploying application efficiently in production.

Deploy application with debug="false"

When we develop asp.net application using Visual Studio, the default value for debug attribute is true. This setting will help developers to debug the application in development environment. For example, executing the application in this mode will not cache the resource files rendered by WebResources.axd handler. This prevents the need to clear the temporary cache every time when the developer needs to check the changes done. There will be other useful things done for developers for debugging like debug symbols, settings that will enable breakpoints etc. These setting will give a poor performance in production if released in the default debug mode (false).

So, never release your website with debug mode set to true. It should be set to false in web.config when moving to production.

 <compilation debug=”false”/>                                                                                                                

Disadvantages of debug = “true”

Ø       Code execution will be slow.

Ø       Compilation will be slow since batch compilation is disabled.

Ø       Memory consumption is higher since there are additional debug symbols, etc.

Ø       Resources downloaded with webresources.axd will not be cached.

Alternate will be <deployment retail=”true”/> in machine.config. If you are a server administrator, make this change in machine.config so that it will enforce the debug attribute in the application’s web.config to false. It also disables the page output tracing and the ability to show the detailed exception report to the remote users when there is an exception.

Read Scott Guthrie’s post about this,

http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

Encrypt the Sensitive data in Web.Config

Sometimes, you will have some sensitive information stored on web.config. For example: SQL Userid and Password if you use SQL authentication to connect to database. Since, the information stored in web.config is clear text then it poses a security risk.

Even though, users can't access web.config file, it is still not safe because the server admins can still see the userid and password from web.config files. For example, in shared hosting environments. So, it will be better if we encrypt the connection string in web.config file in these scenarios.

Understanding this need, Microsoft introduced a new technique to encrypt and decrypt the Web.Config sections in Asp.Net 2.0. ASP.Net 2.0 has 2 providers for encrypting and decrypting config sections,

Ø       RSA(RSAProtectedConfigurationProvider)

Ø       DPAPI(DataProtectionConfigurationProvider)

 To encrypt a connection string section,

protected void btnEncrypt_Click(object sender, EventArgs e)                                                                      

    {

        Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

        ConfigurationSection section = config.GetSection("connectionStrings");

        if (!section.SectionInformation.IsProtected)

        {            section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");

            config.Save();

        }

    }

To use RSA algorithm, use RSAProtectedConfigurationProvider in the place of DataProtectionConfigurationProvider in the above code snippet.

Once encrypted, this section will have encrypted data which is not readable by humans.

The connection string can be still accessed in code by regular ways,

SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["Sql"].ConnectionString);

To see back the original connection string we need to decrypt it.

To decrypt a connection string section,

  protected void btnDecrypt_Click(object sender, EventArgs e)

    {

        Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

        ConfigurationSection section = config.GetSection("connectionStrings");

        if (section.SectionInformation.IsProtected)

        {

            section.SectionInformation.UnprotectSection();

            config.Save();

        }

    }

Use App_Offline.htm to make application Offline

When performing an upgradation of an existing website and if you expect a downtime, then it will be good if we give a generic message to the users accessing the site at that time instead of an error.

The trick is, just include a HTML file called App_Offline.htm in the root directory and include some messages on the page. Anyone trying to access the site at that time will be presented with the content in the App_Offline.htm file. ASP.Net will shutdown the app domain and sends back the content of this html file instead for every request.

App_Offline.htm

<html xmlns="http://www.w3.org/1999/xhtml" >

<head>

    <title>Untitled Page</title>

</head>

<body>

<h3>We are Upgrading!!! Please visit us later!!!</h3>

</body>

</html>                                                                                                                                                       

If the above page content is not showing up on your browser, then just do the following changes in your IE. Open IE > Tools >Internet Options> Advanced > Uncheck "Show Friendly Http error messages".

Use Web Deployment Project to Create Release files

Ø       For Visual Studio 2005, the plug-in can be downloaded here.

Ø       For Visual Studio 2008, the plug-in can be downloaded here.

Features of the Plug-in

The Web Deployment project will provide the following features for building and deploying ASP.NET Web sites:

1.      ASP.NET 2.0 precompilation as part of the build process.

2.      More flexible options for generating compiled assemblies from a Web      project, including these alternatives:

Ø       A single assembly for the entire Web site.

Ø       One assembly per content folder.

Ø       A single assembly for all UI components.

Ø       An assembly for each compiled file in the Web site.

3.      Assembly signing options.

4.      The ability to define custom pre-build and post-build actions.

5.      The ability to exclude folders from the build.

6.      The ability to modify settings in the Web.config file, such as the <connectionString> element, based on the Visual Studio build configuration.

7.      Support for creating .msi files with setup projects.

Configure Custom Error Page in Web.Config file

Use the customError section in web.config to redirect to a generic error page in case of any exception. This will give a better user experience when compared to showing some technical exception messages to the users.

<customErrors defaultRedirect="url"

              mode="On|Off|RemoteOnly">

     <error. . ./>

</customErrors>

mode

On  

Specifies that custom errors are enabled. If no defaultRedirect attribute is specified, users see a generic error. The custom errors are shown to the remote clients and to the local host.

Off

Specifies that custom errors are disabled. The detailed ASP.NET errors are shown to the remote clients and to the local host.

RemoteOnly

Specifies that custom errors are shown only to the remote clients, and that ASP.NET errors are shown to the local host. This is the default value.

You can change this setting accordingly to get the detailed report of an error after deployed to the production.

Separate Application pool

Application Pools a.k.a App Pools is introduced with IIS 6.0 to isolate websites into a group called Application Pools. We can say application pools are a group of one or more URLs that are served by a worker process, means applications running in a single app pools runs in same worker process w3wp.exe, thus providing a boundary so that if one application fails it doesn’t hinder other applications running on other app pools. So as a good practice each website can be assigned with a separate app pool.

Refer my article Deploying ASP.Net Applications to create new application pool.

Custom Service Account

It is the identity of the App pool under which it services the request. It is an windows account that has very less privileges on the server so that we can reduce the security risk and loop holes. There can be several reasons to opt for custom service account over the default Network service account. Some of the reasons are:

Ø       We can have different access controls for different applications on the local and network resources such as fileservers, etc.

Ø       It is also a mode of isolating one application from another by giving a separate identity so other applications cannot access the resource of another application.

Ø       We can prevent any accidental or deliberate changes to the access controls or permissions associated with the general purpose Network Service account from affecting your application.

To create new service account, refer here.

For Intranet applications use Windows Authentication to connect to database

If your application is hosted in an intranet domain, then use windows authentication to connect to the database. The advantage of this approach, you can use the same windows service account configured to run your app pool in IIS 6.0 to connect to the database. This prevents the need to store the password as a clear text in web.config.