his article presents some best practices that you can follow to deploy ASP.NET applications in production mode. These practices help you avoid problems both during and after deployment.

1. Version Your 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.

2. 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

When you execute the preceding command, you’ll see the output shown in Figure 1.

	?
Figure 1. 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")]

3. 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. You can learn more about obfuscation here.

4. 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.

5. Deploy with an Appropriate Strategy
This article covers two main techniques for deploying your ASP.NET web sites: using the Copy Web Site Tool, and using XCOPY deployment. It also briefly touches on Click-Once deployment. The newer of the two main techniques is the Copy Web Site Tool, introduced in ASP.NET 2.0.

Deploying with the Copy Web Site Tool
The steps below show a complete example of copying one web site to another:

1. Create a new web site called SourceWebSite by selecting File ? New ? Web Site in the Visual Studio as shown in Figure 2.

	?
Figure 2. Create New Web Site: Choose the standard ASP.NET Web Site template from the New Web Site dialog.

	?
Figure 3. Copy Web Site: Right-click on the source web site in Solution Explorer and choose Copy Web Site from the context menu.

2. Following the same steps, create another web site called SharedWebSite. You’ll copy this web site to the SourceWebSite using the Copy Web Site tool.
3. Now, select the SourceWebSite in the Visual Studio Solution Explorer, right click on it and select the Copy Web Site option (see Figure 3).
4. Optionally, you can also select the SourceWebSite and click on the Copy Web Site option in the solution explorer as shown in Figure 4.

	?
Figure 4. Quick Web Site Copy: Select the source web site and click the Copy Web Site Option button in the Solution Explorer toolbar.

	?
Figure 5. Open Web Site Dialog: Select the shared/remote web site and click Open.

5. You’ll see the Copy Web Site screen. You’ll see the files from your source web site listed in the left pane.
6. Select the shared web site (your remote web site).

When you do so, the Open Web Site dialog pops up; select the shared/remote web site and click the Open button (see Figure 5).

7. The next screen shows all the files of the shared/remote web site listed in the right pane. Select all the files listed in the Remote Web Site pane as shown in Figure 6.

	?
Figure 6. Selecting Remote/Shared Files: Select all the files from the remote/shared site in the right-hand pane.

	?
Figure 7. Copy Files: Copy selected files between the remote/shared web site and your local web site using the Copy button.

8. Now, click on the Copy Selected Files option button to copy the files from the shared/remote web site to your local web site (see Figure 7).

If the copy process finds file conflicts, it prompts you to confirm whether or not the file(s) should be overwritten (see Figure 8).

	?
Figure 8. File Conflict Resolution: When file conflicts occur, you’ll get a chance to decide how the copy process should resolve the conflict.

If the sites have identically-named subfolders, you can easily synchronize the source and remote web sites by selecting the “Synchronize Files” option as shown in Figure 9.

	?
Figure 9. Synchronize Files: Clicking this button synchronizes selected files between the remote and local servers for files in matching paths.

That completes the Copy Web Site process.

5. Deploy with an Appropriate Strategy (continued)
Deploying with XCOPY
Deploying an ASP.NET application in the production server is simple: Just use the XCOPY command to copy your application’s entire folder structure to the production environment. Here’s the XCOPY procedure:

1. Open a console window by clicking on Start ? Run
2. Type cmd and press enter
3. Create the same folder structure at the target location where you would copy your web site.
4. Finally, type the following command at the command prompt, using your path information (see Figure 10).

      XCOPY DevXSharedWebSite DevXSourceWebSite /e /r /k /h /i /y 

	?
Figure 10. XCOPY Example: The XCOPY command using the options shown in the figure copies all directories, subdirectories, and files to the shared web site.

The preceding command copies the SharedWebsite folder and its subdirectories to the c:DevXSourceWebSite folder on the production system. Here’s an explanation of the specified options:

• /e: Copy all directories and subdirectories, including empty ones
• /r: Overwrite existing read-only files
• /h: Copy system and hidden files and directories
• /k: Copy file and directory attributes
• /y: Suppresses “overwrite existing file” confirmation messages

You can easily deploy one or more files from the command prompt using the XCOPY command. To deploy a single file, use a command such as this:

   XCopy E:MyAppMyAppAssembly.dll C:InetPubwwwrootin

To deploy all DLL files, you could use this command:

   Xcopy E:MyApp*.dll C:InetPubwwwrootin

XCOPY vs. the Copy Web Site Tool
Now that you’ve seen both methods, which should you use? Using the Copy Web Site Tool has one major disadvantage compared to XCOPY deployment?the initial load time of your web pages is slower. That’s because The Copy Web Site Tool copies all your source pages as source, and the Copy Web Site technique performs no compilation. In addition, copying the source files injects a potential risk to your intellectual property, because people can see the source. However, Copy Web Site improves on XCOPY because you can use it to deploy your application to a file system, a local instance of Internet Information Server (IIS), FTP sites, or even to remote sites seamlessly.

6. Pre-Compile Your Sites
You can use the ASP.NET 2.0 Precompilation feature to minimize the initial load time of your web pages, and avoid having to deploy your source code to the server. Precompilation 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. Precompilation can both reduce application response time and improve performance. A full discussion of precompilation is beyond the scope of this article, but you can learn more in this article.

7. 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.

8. Take Advantage of Click-Once Deployment and Automated Updates
Click-Once deployment is a strategy introduced with Microsoft .NET 2.0 that you can use to deploy an application to a file system, local web server, remote web site, or FTP site.

The essence of Click-Once is that you have an application on the client that can detect when updates are available and download them, allowing you to configure your application to get updates securely and periodically over the internet. Click-Once provides you with lower costs and automated updates with no version conflicts! You can use the Click-Once deployment strategy to provide hot updates to the application, downloading and installing only libraries that have changed. However, there may be situations when Click-Once does not work the way you expected. For example, if a client’s browser’s proxy server has already cached an older version of the deployment file, that client might not get the updates as expected. Use HTTP content expiration to mitigate such issues.

Some Final Points

• Before you deploy your application, ensure that the Compilation Debug attribute is set to false in your application’s web.config file. When set to true, your application consumes more memory and processing time, and scripts and images downloaded from the web server do not get cached locally.
• Build your assemblies in Release mode before you deploy the application to the production server.
• Ensure that you allow IIS to process dynamic contents by setting the Web Service Extensions to “enabled” mode.
• Ensure that you have encrypted all configuration data that your application makes use of, such as connection strings, etc.
• Remember to use Http compression through IIS to compress the size of the rendered response and improve overall application performance.

Finally, it’s advisable to prepare a checklist that lists the deployment steps you have chosen follow; you can cross-check against that list to ensure that you haven’t skipped any steps.

As you can see, there are plenty of strategies for deploying ASP.NET applications to a production environment. By being aware of the options, selecting the best deployment model for your application, preparing a checklist, and using it to verify if the best practices documented there, you’ll find that production deployments can go very smoothly.