Best Practices for ASP.Net Application Production deployment

1.    Use trusted SQL connections with integrated authentication 

To make the production environment more secure, one of the things we looked into was securing the database connection information between the web server and SQL server.

2.    Use the Aspnet_setreg.exe utility to encrypt the connection string and store it in the registry.

How to use this utility – Refer http://msdn.microsoft.com/en-us/library/aa302406.aspx

3.    Using DPAPI (Data Protection application programming interface) to secure the connection string  

How to use this DPAPI – Refer http://msdn.microsoft.com/en-us/library/aa302403.aspx

4.    Set retail=”true” in your machine.config in the production server 

<configuration>

<system.web>

<deployment retail=”true”/>

</system.web>

</configuration>

 It will force the ‘debug’ flag in the web.config to be false, disable page output tracing, and also force the custom error page to be shown to remote users rather than the actual exception or error message. Refer  https://c2blogs.cognizant.com/blogs/188281/2009/12/16/deployment-element-force-the-debug-flag-in-the-webconfig-to-be-false/

5.    Create a new application pool for your site 

When setting up your new site for the first time do not share an existing application pool.  Create a new application pool which will be used by only by the new web application.

6.    Set the memory limit for your application pool 

When creating the application pool, specifically set the memory limit rather than the time limit which is set by default.  Asp.net has a good whitepaper (http://www.asp.net/learn/whitepapers/aspnet-and-iis6/ ) which explains the value of this: By default IIS 6.0 does not set a limit on the amount of memory that IIS is allowed to use. ASP.NET’s Cache feature relies on a limitation of memory so the Cache can proactively remove unused items from memory.  It is recommended that you configure the memory recycling feature of IIS 6.0.

7.    Create and appropriately use an app_Offline.htm file 

There are many benefits to using this file.  It provides an easy way to take your application offline in a somewhat user friendly way (you can at least have a pretty explanation) while fixing critical issues or pushing a major update.  It also forces an application restart in case you forget to do this for a deployment.

8.    Develop a repeatable deployment process and automate it

It is way too easy to make mistakes when deploying any type of software.  This is especially the case with software that uses configuration files that may be different between the development, staging, or production environments.  I would argue that the process you come up with is not nearly as important as it being easily repeatable and automated.  You can fine tune the process as needed, but you don’t want a simple typo to bring a site down.

9.    Build and reference release versions of all assemblies / Version Your Assemblies 

In addition to making sure ASP.NET is not configured in debug mode, also make sure that your assemblies are not debug assemblies.  There are of course exceptions if you are trying to solve a unique issue in your production environment … but in most cases you should always deploy with release builds for all assemblies

Make sure you have a solid versioning policy in place. You can apply a version stamp using the AssemblyVersion attribute at compile time, for example:

[assembly: AssemblyVersion(“1.0.12.34”)]

It’s usually best to apply the same version number to all the assemblies in an application during the build process.

10.  Give Assemblies Strong Names 

An assembly is the smallest unit of versioning, security, deployment, version control and reusability of code in .NET. Each assembly contains:

Assembly Identity information (name, version, etc.)

Manifest and metadata information

MSIL code

Type and security information

Resources

An assembly with a strong name can be uniquely identified by a combination of its assembly version, culture information, and a digital signature.

You can create a strong name for your assembly using the strong name utility (sn.exe) provided by the .NET framework.

The utility requires you to provide the name of a strong name key file as a parameter. The resulting file is called a “strong-named” file. You can use the sn.exe tool from the command line to create a strong-named key file as follows:    sn –k MyCompany.snk,

Creating a Strong-Named Key File: Running the sn.exe file from the command line as shown creates a strong-named key file.

When you create a project in Visual Studio, you’ll see a default file called AssemblyInfo.cs that you can use to specify the related attributes.

Here is how you can specify the strong name information in the AssemblyInfo.cs file.

[assembly: AssemblyCulture(“”)]

[assembly: AssemblyVersion(“1.0.0.0”)]   [assembly: AssemblyKeyFile(“MyCompany.snk”)]

11.  Obfuscate Your Assemblies 

It’s good practice to obfuscate your assemblies before you deploy them; obfuscation makes assemblies more difficult to decompile, and impedes reverse-engineering efforts, thus protecting your source code to some degree from potential threats. In addition, obfuscation reduces the size of your assemblies; thereby boosting the application’s performance.

12.  Deploy Shared Assemblies to the GAC 

You should deploy assemblies used by multiple applications to the Global Assembly Cache (commonly known as the GAC), which allows them to be shared by all applications that use the assembly. Deploying an assembly to the GAC improves its load performance compared to assemblies not located in the GAC. Strong-named assemblies load faster from the GAC because they’re verified at install time rather than at runtime—the .NET framework skips verification at runtime for GAC-loaded assemblies. The runtime always checks strong-named assemblies to verify their integrity. .NET refuses to load assemblies that are not trusted or that may have been tampered with. Note that you must provide a strong name for assemblies you want to install in the GAC.

You place an assembly into the GAC using the GACUtil tool. The following command places MyProject.dll into the GAC, thus making it globally accessible.

GacUtil /i MyProject.dll

To uninstall the assembly from the GAC, you would use:    GacUtil /u MyProject.dll

Note that you can even make your strong-named assembly globally accessible without placing it in the GAC. For this, you need to deploy your assembly using the XCOPY command.

13.  Pre-Compile Your Sites 

You can use the ASP.NET 2.0 Pre compilation feature to minimize the initial load time of your web pages, and avoid having to deploy your source code to the server. Pre compilation is a great new feature that can detect and provide warnings about any compilation failure issues. It lets you deploy applications without having to store any source code on the deployment server. Pre compilation can both reduce application response time and improve performance. Learn more about pre compile http://www.devx.com/dotnet/Article/34418/0

14.  Reduce File Sizes 

It’s generally a good practice to squeeze extra white space and other unwanted characters from your web pages, script, and style sheets to minimize response size. You can also compress the rendered response to reduce network bandwidth and improve performance using IIS compression. Although there is a slight performance penalty for using IIS compression (compression requires extra processing), it’s still a good practice, because the performance penalty is negligible compared to the huge benefit you get from it; compression can reduce network bandwidth by nearly 50 percent! This article provides more information on file size reduction and IIS HTTP compression.

REF MSDN