Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1525
Chapter 33: Administration and Management
Figure 33-36
Figure 33-37
You can apply state management to your applications in a number of ways, and this dialog allows for
a number of different settings — some of which are enabled or disabled based on what is selected. The
following list describes the items available in the Session State Settings section:
❑ Session state mode: Determines how the sessions are stored by the ASP.NET application. The
default option (shown in Figure 33-38) is InProc. Other options include Off, StateServer, and
SQLServer. Running sessions in-process (InProc) means that the sessions are stored in the same
process as the ASP.NET worker process. Therefore, if IIS is shut down and then brought up
again, all the sessions are destroyed and unavailable to end users. StateServer means that ses-
sions are stored out-of-process by a Windows service called ASPState. SQLServer is by far the
most secure way to deal with your sessions — it stores them directly in SQL Server. StateServer
is also the least performance-efficient method.
1525
Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1526
Chapter 33: Administration and Management
Figure 33-38
❑ Cookieless mode: Changes how the identifiers for the end user are stored. The default setting
uses cookies (UseCookies). Other possible settings include UseUri, AutoDetect, and UseDevice-
Profile.
❑ Session timeout: Sessions are stored for only a short period of time before they expire. For years,
the default has been 20 minutes. Modifying the value here changes how long the sessions created
by your application are valid.
SMTP E-mail
If you need to work with an application that delivers e-mail, then you must specify the settings to do this.
Sending e-mail and the settings required are defined in the SMTP E-mail section (see Figure 33-39).
1526
Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1527
Chapter 33: Administration and Management

Figure 33-39
Summary
This chapter showed you some of the new management tools that come with the latest release of
ASP.NET. These tools make the ever-increasing size of the
web.config
file more manageable because
they take care of setting the appropriate values in the application’s configuration file.
The new IIS Manager console in Windows Vista is a welcome addition for managing applications that
are configured to work with IIS. The ASP.NET Web Site Administration Tool provides even more value
to administrators and developers by enabling them to easily manage settings.
1527
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1529
Packaging and Deploying
ASP.NET Applications
Packaging and deploying ASP.NET applications are topics that usually receive little attention. This
chapter is going to take a more in-depth look at how you can package and deploy your ASP.NET
applications after they are built. After you have developed your ASP.NET application on a devel-
opment computer, you will need to deploy the finished product to a quality assurance or staging
server, and eventually on a production server.
An important reason to consider the proper packaging and deploying of your ASP.NET appli-
cations is that many applications are built as saleable products, starter kits, or solutions. In this
case you may have to allow complete strangers to download and install these products in their
own — environments that you have absolutely no control over. If this is the case, it is ideal to
give the consumer a single installer file that ensures proper installation of the application in any
environment.
But regardless of whether you will distribute your web application outside your company you still
need a way to deploy it to another server where it can be tested before production deployment.
You should never assume that it will be perfect just because it worked on your computer. Most of
the time we just develop using the internal web server in Visual Studio, so we will need a full test
using IIS before we assume all is well. Even if you do test with IIS on your computer there are still

deployment related factors that need to be ironed out and fully tested before the application goes to
production.
Before you start, you should understand the basics of packaging and deploying ASP.NET applica-
tions. In the process of packaging your ASP.NET applications, you are putting your applications
into a package and utilizing a process of deployment that is initiated through a deployment
procedure, such as using a Windows installer.
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1530
Chapter 34: Packaging and Deploying ASP.NET Applications
Deployment Pieces
So what are you actually deploying? ASP.NET contains a lot of pieces that are all possible parts of the
overall application and need to be deployed with the application in order for it to run properly. The
following list details some of the items that are potentially part of your ASP.NET application and need
deployment consideration when you are moving your application:
❑
.aspx
pages
❑ The code-behind pages for the
.aspx
pages (
.aspx.vb
or
.aspx.cs
files)
❑ User controls (
.ascx
)
❑ Web service files (
.asmx
and
.wsdl

files)
❑
.htm
or
.html
files
❑ Image files such as
.jpg
or
.gif
❑ ASP.NET system folders such as
App_Code
and
App_Themes
❑ JavaScript files (
.js
)
❑ Cascading Style Sheets (
.css
)
❑ Configuration files such as the
web.config
file
❑ .NET components and compiled assemblies
❑ Data files such as
.mdb
files
Steps to Take before Deploying
Before deploying your ASP.NET Web applications, you should take some basic steps to ensure that your
application is ready for deployment. These steps are often forgotten and are mentioned here to remind

you of how you can ensure that your deployed application performs at its best.
The first step you should take is to turn off debugging in the
web.config
file. You do this by setting the
debug
attribute in the <
compilation
> element to
false
, as shown in Listing 34-1.
Listing 34-1: Setting debug to false before application deployment
<
configuration xmlns=" />>
<
system.web
>
<
compilation debug="false" /
>
<
/system.web
>
<
/configuration
>
By default, most developers set the
debug
attribute to
true
when developing their applications. Doing

this inserts debug symbols into the compiled ASP.NET pages. These symbols degrade the performance
of any application. After the application is built and ready to be deployed, it is unnecessary to keep these
debug symbols in place.
For those that have been coding ASP.NET for some time now, it is important to note that the Debug
option in the drop-down list in the Visual Studio menu does not accomplish much in changing the
1530
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1531
Chapter 34: Packaging and Deploying ASP.NET Applications
configuration file or anything similar (shown here in Figure 34-1). In the ASP.NET 1.0 and 1.1 days, Visual
Studio .NET (as it was called at that time) actually controlled the compilation of the ASP.NET project to
a DLL. Now, and ever since ASP.NET 2.0, it is actually ASP.NET itself that controls the compilation
process at runtime. Therefore, while the drop-down with the Debug designation is present, it really
has no meaning in the context of building an ASP.NET project. You completely control the compilation
designation through what is set in the
web.config
file, as shown in Listing 34-1.
Figure 34-1
Methods of Deploying Web Applications
Remember that deployment is the last step in a process. The first is setting up the program — packaging
the program into a component that is best suited for the deployment that follows. You can actually deploy
a Web application in a number of ways. You can use the XCopy capability that simply wows audiences
when demonstrated (because of its simplicity). A second method is to use Visual Studio 2008’s capability
to copy a Web site from one location to another using the Copy Web Site feature, as well as an alternative
method that uses Visual Studio to deploy a precompiled Web application. The final method uses Visual
Studio to build an installer program that can be launched on another machine. After reviewing each of
the available methods, you can decide which is best for what you are trying to achieve. Start by looking
at the simplest of the three methods: XCopy.
Using XCopy
Because of the nature of the .NET Framework, it is considerably easier to deploy .NET applications
now than it was to deploy applications constructe d using Microsoft’s predecessor technology — COM.

Applications in .NET compile down to assemblies, and these assemblies contain code that is executed by
the Common Language Runtime (CLR). One great thing about assemblies is that they are self-describing.
All the details about the assembly are stored within the assembly itself. In the Windows DNA world,
COM stored all its self-describing data within the server’s registry, so installing (as well as uninstalling)
COM compone nts meant shutting down IIS. Because a .NET assembly stores this information within
itself, XCOPY deployment is possible and no registry settings are needed. Installing an assembly is as
simple as copying it to another server and you do not need to stop or start IIS while this is going on.
We mention XCOPY here because it is the command-line way of basically doing a copy-and-paste of the
files you want to move. XCOPY, however, provides a bit more functionality than just a copy-and-paste,
as you w ill see shortly. XCOPY enables you to move files, directories, and even entire drives from one
point to another.
The default syntax of the XCOPY command is as follows:
xcopy [source][destination] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g]
1531
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1532
Chapter 34: Packaging and Deploying ASP.NET Applications
[/d[:mm-dd-yyyy]] [/u] [/i] [/s [/e]] [/t] [/k] [/r] [/h] [{/a|/m}] [/n] [/o]
[/x] [/exclude:file1[+[file2]][+file3]] [{/y|/-y}] [/z]
To see an example of using the XCOPY feature, suppose you are working from your developer machine
(
C:
\) and want to copy your ASP.NET application to a production server (
Z:
\). In its simplest form, the
following command would do the job:
xcopy c:
\
Websites
\
Website1 y:

\
Websites
\
/f /e /k /h
This move copies the files and folders from the source drive to the destination drive. Figure 34-2 shows
an example of this use on the command line.
Figure 34-2
When you copy files using XCOPY, be aware that this method does not allow for the automatic creation
of any virtual directories in IIS. When copying a new web application, you also need to create a
virtual directory in the destination server and associate this virtual directory with the application you are
copying. It is a simple process, but you must take these extra steps to finalize the site copy actions.
You can provide a number of parameters to this XCOPY command to get it to b ehave as you want it to.
The following table details these parameters.
Parameter Description
/w
Displays the me ssage:
Press any key to begin copying file(s)
. It waits for your
response to start the copying process.
/p
Asks for a confirmation on each file being copied. This is done in a file-by-file
manner.
/c
Ignores errors that might occur in the copying proce ss.
/v
Performs a verification on the files being copied to make sure they are identical to
the source files.
/q
Suppresses any display of the XCOPY messages.
/f

Displays the file names for the source and destination files while the copying
process is occurring.
1532
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1533
Chapter 34: Packaging and Deploying ASP.NET Applications
Parameter Description
/l
Displays a list o f the files to be copied to the destination drive.
/g
Builds decrypted files for the destination drive.
/d
When used as simply
/d
, the only files copied are those newer than the existing files
located in the destination location. Another alternative is to use
/d[:mm-dd-yyyy]
,
which copies files that have been modified either on or after the specified date.
/u
Copies only source files that already exist in the destination location.
/i
If what is being copied is a directory or a file that contains wildcards and the same
item does not exist in the destination location, a new directory is created. The
XCOPY process also copies all the associated files into this directory.
/s
Copies all directories and their subdirectories only if they contain files. All empty
directories or subdirectories are not copied in the process.
/e
Copies all subdirectories regardless of whether these directories contain files.
/t

Copies the subdirectories only and not the files they might contain.
/k
By default, the XCOPY process removes any read-only settings that might be
contained in the source files. Using
/k
ensures that these read-only settings remain
in place during the copying process.
/r
Copies only the read-only files to the destination location.
/h
Specifies that the hidden and system files, which are usually excluded by default,
are included.
/a
Copies only files that have their archive file attributes set, and leaves the archive file
attributes in place at the XCOPY destination.
/m
Copies only files that have their archive file attributes set, and t urns off the archive
file attributes.
/n
Copies using the NTFS short file and short directory names.
/o
Copies the discretionary access control list (DACL) in addition to the files.
/x
Copies the audit settings and the system access control list (SACL) in addition to the
files.
/exclude
Allows you to exclude specific files. The construction used for this is
exclude:
File1.aspx + File2.aspx + File3.aspx
.

/y
Suppresses any prompts from the XCOPY process that ask whether to overwrite the
destination file.
/-y
Adds prompts in order to confirm an overwrite of any existing files in the
destination location.
/z
Copies files and directories over a network in restartable mode.
/?
Displays help for the XCOPY command.
1533
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1534
Chapter 34: Packaging and Deploying ASP.NET Applications
Using XCOPY is an easy way to move your applications from one server to another with little work on
your part. If you have no problem setting up your own virtual directories, this mode of deployment
should work just fine for you.
When the Web application is copied (and if placed in a proper virtual directory), it is ready to be called
from a browser.
Using the VS Copy Web Site Option
The next option for copying a Web site is to use a GUI provided by Visual Studio 2008. This Copy Web
Site GUI enables you to copy Web sites from your development server to either the same server or a
remote server (as you can when you use the XCOPY command).
You can pull up this Copy Web Site dialog in Visual Studio in two ways. The first way is to click in the
Copy Web Site icon in the Visual Studio Solution Explorer. T his icon is shown in Figure 34-3.
Figure 34-3
The other way to open the Copy Web Site GUI is to choose Website ➪ Copy Web Site from t he Visual
Studio menu. Using either method pulls up the Copy Web Site GUI in the Document window, as
illustrated in Figure 34-4.
From this GUI, you can click the Connect To a Remote Server button (next to the Connections text box).
This action brings up the Open Web Site dialog shown in Figure 34-5.

1534
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1535
Chapter 34: Packaging and Deploying ASP.NET Applications
Figure 34-4
As you can see from this dialog, you have a couple of options to connect to and copy your Web applica-
tion. These options include the following:
❑ File System: This option allows you to navigate through a file explorer view of the computer.
If you are going to install on a remote server from this view, you must have already mapped
a drive to the installation location.
❑ Local IIS: This option enables you to use your local IIS in the installation of your Web applica-
tion. From this part of the dialog, you can create new applications as well as new virtual direc-
tories directly. You can also delete applications and virtual directories from the same dialog. The
Local IIS option does not permit you to work with IIS installations on any remote servers.
❑ FTP Site: This option enables you to connect to a remote server using FTP capabilities. From this
dialog, you can specify the server that you want to contact using a URL or IP address, the port
you are going to use, and the directory on the server that you will work with. From this
dialog, you can also specify the username and password that may be required to access the
server via FTP. Note that if you access this server with this dialog via FTP and p rovide a user-
name and password, the items are transmitted in plain text.
❑ Remote Site: This option enables you to connect to a remote site using FrontPage Server Exten-
sions. From this option in the dialog, you can also choose to connect to the remote server using
Secure Sockets Layer (SSL).
1535