Eight Key Practices for ASP.

NET Deployment

http://www.devx.com Printed from http://www.devx.com/dotnet/Article/38462/1954

Eight Key Practices for ASP.NET Deployment

Discover some best practices for deploying ASP.NET applications as well as a
few useful procedures that you can follow to improve your application's
performance.

by Joydip Kanjilal

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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (1 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

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

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("")] Figure 1. Creating a Strong-

[assembly: AssemblyVersion("1.0.0.0")] Named Key File: Running the
[assembly: AssemblyKeyFile("MyCompany. <i>sn.exe</i> file from the
snk")] command line as shown
creates a strong-named key file.
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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (2 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

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.

http://www.devx.com/dotnet/Article/38462/1954?pf=true (3 of 10) [6/4/2010 4:19:30 PM]

Eight Key Practices for ASP.NET Deployment

Figure 2. Create New Web Site: Choose

the standard ASP.NET Web Site
template from the New Web Site dialog.

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 Figure 3. Copy Web Site: Right-click on

SourceWebSite and click on the Copy Web the source web site in Solution

Site option in the solution explorer as shown Explorer and choose Copy Web Site
in Figure 4. from the context menu.

Figure 4. Quick Web Site Copy: Select

the source web site and click the Copy
Web Site Option button in the Solution
Explorer toolbar.

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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (4 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

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 5. Open Web Site Dialog:

Select the shared/remote web
site and click Open.

Figure 6. Selecting Remote/Shared

Files: Select all the files from the
remote/shared site in the right-hand
pane.

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

Figure 7. Copy Files: Copy

If the copy process finds file conflicts, it prompts you to
selected files between the
confirm whether or not the file(s) should be overwritten (see
remote/shared web site and
Figure 8).
your local web site using the
Copy button.

http://www.devx.com/dotnet/Article/38462/1954?pf=true (5 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (6 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

XCOPY DevX\SharedWebSite DevX\SourceWebSite /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.

Author's Note: When you use XCOPY from Microsoft's Vista OS, you'll see a message
reading: "XCOPY is now deprecated; please use ROBOCOPY." ROBOCOPY stands for

"Robust File Copy." In Vista, you can find more information by typing ROBOCOPY /? at a

command line.

The preceding command copies the SharedWebsite folder and its subdirectories to the c:\DevX
\SourceWebSite 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:\MyApp\MyAppAssembly.dll C:\InetPub\wwwroot\bin

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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (7 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

Xcopy E:\MyApp\*.dll C:\InetPub\wwwroot\bin

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

http://www.devx.com/dotnet/Article/38462/1954?pf=true (8 of 10) [6/4/2010 4:19:30 PM]

 Eight Key Practices for ASP.NET Deployment

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.

Joydip Kanjilal has over 10 years of industry experience with C, C++, Java, C#, VB, VC++, ASP.
Net, XML, Design Patterns, UML, etc. He currently works as a senior project leader in a reputable
multinational company in Hyderabad, India, and has contributed articles on .NET and related
techonlogies to www.aspalliance.com.

http://www.devx.com/dotnet/Article/38462/1954?pf=true (9 of 10) [6/4/2010 4:19:30 PM]

Eight Key Practices for ASP.NET Deployment

DevX is a division of Internet.com.

© Copyright 2010 Internet.com. All Rights Reserved. Legal Notices

http://www.devx.com/dotnet/Article/38462/1954?pf=true (10 of 10) [6/4/2010 4:19:30 PM]