Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1556
Chapter 34: Packaging and Deploying ASP.NET Applications
Property Description
LogVisits
Specifies the IIS Log Visits property for the selected folder. The
default value is
True
.
VirtualDirectory
Defines the name of the virtual directory created. The default
value is the name of the project.
Adding Items to the Output
You can add files, folders, and assemblies to the installer output quite easily. To add some of these items
to the output list, right-click the folder and select Add from the menu. You have four choices: Web Folder,
Project Output, File, and Assembly.
If you want to add a custom folder to the output (for example, an Images folder), you can select Web
Folder and provide the name of the folder. This enables you to create the f older structure you want.
If you want to add system folders, you highlight the File System on Target Machine n ode and then
choose Action ➪ Add Special Folder. This provides you with a large list of f olders that are available for
you to add to the installer program. You can also get at this list of folders by simply right-clicking a blank
portion of the left pane of the File System Editor (see Figure 34-25).
The following table defines the possible folders you can add to the installer structure you are building.
Folders and Menus Description
Common Files Folder Meant for non–system files not shared by multiple
applications.
Common Files (64-bit) Folder Meant for non–system files on a 64-bit machine not shared by
multiple applications.
Fonts Folder Meant for only fonts you want installed on the client’s
machine.
Program Files Folder A Windows Forms application would be a heavy user of this
folder because most applications are installed here.

Program Files (64-bit) Folder A Programs Files folder meant for 64-bit machines.
System Folder Meant for storing files considered shared system files.
System (64-bit) Folder Meant for storing files on 64-bit machines considered shared
system files.
User’s Application Data Folder A hidden folder meant for storing data that is application- and
user-specific.
User’s Desktop Meant for storing files on a user’s desktop (also stores these
files in the My Desktop folder).
User’s Favorites Folder Meant for storing files in a user’s Favorites folder (browser-
specific).
1556
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1557
Chapter 34: Packaging and Deploying ASP.NET Applications
Folders and Menus Description
User’s Personal Data Folder Meant for storing personal data specific to a single user. This is
also referred to as the My Documents folder.
User’s Programs Menu Meant for storing shortcuts, which then appear in the user’s
program menu.
User’s Send To Menu Meant for storing files that are presented when a user attempts
to send a file or folder to a specific application (by
right-clicking the folder or file and selecting Send To).
User’s Start Menu Meant for storing files in the user’s Start menu.
User’s Startup Folder Meant for storing files that are initiated whenever a user logs
into his machine.
User’s Template Folder Meant for storing templates (applications like Microsoft’s
Office).
Windows Folder Meant for storing files in the Windows root folder. These are
usually system files.
Global Assembly Cache Folder Meant for storing assemblies that can then be utilized by all
the applications on the server (shared assemblies).

Custom Folder Another way of creating a unique folder.
Web Custom Folder Another way of creating a unique folder that also contains a
bin folder.
Creating a Desktop Shortcut to the Web Application
For an example of using one of these custom folders, look at placing a shortcut to the Web application
on the user’s desktop. The first step is to right-click on a blank portion of the left-hand pane in the File
System Editor and choose Add Special Folder ➪ User’s Desktop. This adds that folder to the list of folders
presented in the left-hand pane.
Because you want to create a desktop shortcut to the Web Application Folder and not to the desktop itself,
the next step is to right-click the Web Application folder and select Create Shortcut to Web Application
Folder. The created shortcut appears in the right-hand pane. Right-click the shortcut and rename it to
something a little more meaningful, such as Wrox Application. Because you do not want to keep the
shortcut in this folder, drag the shortcut from the Web Application Folder and drop it onto the User’s
Desktop folder.
With this structure in place, this installer program not only installs the application (as was done previ-
ously), but it also installs the application’s shortcut on the user’s desktop.
The Registry Editor
The next editor is the Registry Editor. This editor enables you to work with the client’s registry in an easy
and straightforward manner. Using t his editor, you can perform operations such as creating new registry
1557
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1558
Chapter 34: Packaging and Deploying ASP.NET Applications
keys, providing values for already existing registry keys, and importing registry files. The Registry Editor
is presented in Figure 34-26.
Figure 34-25
From this figure, you can see that the left-hand pane provides the standard registry folders, such as
HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE, as well as others. Right-clicking one of these
folders, you can add a new key from the menu selection. This creates a new folder in the left-hand pane
where it is enabled for renaming. By right-clicking this folder, you can add items such as those illustrated
in Figure 34-27.

As you can see in the figure, you can add items such as the following:
❑ Key
❑ String Value
1558
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1559
Chapter 34: Packaging and Deploying ASP.NET Applications
❑ Environment String Value
❑ Binary Value
❑ DWORD Value
Figure 34-26
Figure 34-27
Selecting String Value allows you to apply your settings for this in the right-hand pane, as illustrated in
Figure 34-28.
The other values work in a similar manner.
The File Types Editor
All files on a Windows operating system use file extensions to uniquely identify themselves. A file such
as
Default.aspx
, for example, uses the file extension
.aspx
. This file extension is then associated with
1559
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1560
Chapter 34: Packaging and Deploying ASP.NET Applications
Figure 34-28
ASP.NET. Another example is
.xls
. This file extension is associated with Microsoft Excel. When someone
attempts to open an
.xls

file, the file is passed to the Excel program because of mappings that have been
made on the computer to associate these two entities.
Using the File Types Editor in Visual Studio, you can also make these mappings for the applications
you are trying to install. Right-clicking the File Types On Target Machine allows you to add a new file
type. From here, you can give your file type a descriptive name and provide a file extension (shown in
Figure 34-29).
Figure 34-29
Highlighting the defined file type provides some properties that you can set in the Visual Studio Proper-
ties window, as shown in the following table.
Property Description
Name
Specifies a name used in the File System Editor to identify a file type and its
associated settings.
Command
Specifies the executable file (
.exe
) that is launched when the specified file e xtension
is encountered.
Description
Defines a textual description for the file type.
1560
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1561
Chapter 34: Packaging and Deploying ASP.NET Applications
Property Description
Extensions
Defines the file extension associated with the executable through the
Command
property. An example is
wrox
. You should specify the extension without the period

in front of it. If you are going to specify multiple extensions, you can provide a list
separated by semicolons.
Icon
Defines the icon used for this file extension.
MIME
Specifies the MIME type associated with this file type. An example is
application/msword
.
The User Interface Editor
The User Interface Editor defines the dialogs used in the installation process. You can change the instal-
lation process greatly with the dialogs you decide to use or not use. By default, these dialogs (shown in
Figure 34-30) are presented in your installer.
Figure 34-30
From this figure, you can see how the dialogs are divided into two main sections. The first section,
labeled Install, is the dialog sequence used for a typical install. However, because some applications
1561
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1562
Chapter 34: Packaging and Deploying ASP.NET Applications
might require it, a second installation process is defined through the Administrative Install. The Admin-
istrative Install process is initiated only if the user is logged onto the machine under the Administrator
account. If this is not the case, the Install section is used instead.
By default, the Install and Administrative Install sections are exactly the same. Both the Install and
Administrative Install sections are further divided into three subsections: Start, Progress, and End. T hese
sections are defined in the following list:
❑ Start: A sequence of dialogs that appears before the installation occurs. By default, the Start
section includes a welcome screen, a definition stating where the application is to be installed,
and a dialog asking for an installation confirmation.
❑ Progress: The second stage, the Progress stage, is the stage in which the actual installation
occurs. Throughout this stage no interaction occurs between the installer program and the end
user. This is the stage where the end user can watch the installation progress through a progress

bar.
❑ End: The End stage specifies to the end user w hether the installation was successful. Many
installer programs use this stage to present the customer with release notes and
ReadMe.txt
files, as well as the capability to launch the installed program directly from the installer program
itself.
Adding Dialogs to the Installation Process
Of course, you are not limited to just the dialogs that appear in the User Interface Editor by default. You
have a number of other dialogs that can be added to the installation process. For instance, right-click the
Start node and select Add Dialog (or highlight the Start node and choose Action ➪ Add Dialog). This
pulls up the Add Dialog dialog, as shown in Figure 34-31.
As you can see from this image, you can add quite a number of different steps to the installation process,
such as license agreements and splash screens. After adding a dialog to the process, you can highlight the
dialog to get its properties to appear in the Properties window so that you can assign the items needed.
For example, you can assign the image to use for the splash screen or the
.rtf
file to use for the license
agreement.
When you add an additional dialog to the installation process (for instance, to the Install section), be sure
to also install the same dialog on the Administrative Install (if required). If no difference exists between
the two user types in the install process, be sure to add the dialogs in unison in order to keep them the
same.
Changing the Order in Which the Dialogs Appear in the Process
In working with the dialogs in the Start, Process, and End sections of the User Interface Editor, you can
always determine the order in which these dialogs appear. Even if you are working with the default
dialogs, you can easily change their order by right-clicking the dialog and selecting Move Up or Move
Down, as shown in Figure 34-32.
The Custom Actions Editor
The Custom Actions Editor is a powerful editor that enables you to take the installer one step further and
perform custom actions during various events of the installation cycle (but always after the installation

1562
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1563
Chapter 34: Packaging and Deploying ASP.NET Applications
Figure 34-31
process is completed) such as Install, Commit, Rollback, and Uninstall. The Custom Actions Editor is
presented in Figure 34-33.
Theideaisthatyoucanplaceareferencetoa
.dll
,
.exe
,or.
vbs
file from one of the folders presented
here in the Custom Actions Editor to perform a custom action. For example, you can insert a custom
action to install a database into Microsoft’s SQL Server in the Commit folder (after the install has actually
been committed).
The four available folders are explained in the following list:
❑ Install: This is the point at which the installation of the files for the Web application are finished
being installed. Although the files are installed, this point is right before the installation has been
committed.
❑ Commit: This is the point at which the actions of the installation have been actually committed
(taken) and are considered successful.
❑ Rollback: This is the point at which the installation has failed and the computer must return to
the same state that it was in before the installation occurred.
❑ Uninstall: This is the point at which a successfully installed application is uninstalled for a
machine.
1563
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1564
Chapter 34: Packaging and Deploying ASP.NET Applications
Figure 34-32

Figure 34-33
Using these capabilities, you can take the installation process to the level of complexity you need for a
successfully installed application.
The Launch Conditions Editor
Certain conditions are required in order for your Web application to run on another server automatically.
Unless your application is made up of HTML files only, you must make sure that the .NET Framework is
1564
Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1565
Chapter 34: Packaging and Deploying ASP.NET Applications
installed on the targeted machine in order to consider the install a success. The Launch Conditions Editor
is an editor that you can use to make sure that everything that needs to be in place on the installation
computer for the installation to occur is there. The Launch Conditions Editor is presented in Figure 34-34.
Figure 34-34
From this image, you can see some of the conditions required in this instance. The first folder defines
the items that must be in place on the computer where the installation is to occur. A search is done on the
computer to see whether IIS is installed. It can also check if any files or registry keys are present on
the computer before the installation occurs.
The second folder is an important one because certain conditions must be in place before the installation.
This folder shows two conditions. One is that the .NET Framework must be installed, and the second is
that IIS must be installed. You can add these types of launch conditions by right-clicking the Require-
ments On Target Machine node in the dialog. You are then presented with a short list of conditions.
After a condition is in place, you can highlight the condition to see the property details of this condi-
tion in the Properties window. For instance, highlighting the IIS Condition gives you some basic proper-
ties in the Properties window. One of these is the
Condition
property. By default, for an IIS Condition,
the value of the
Condition
property is the following:
IISVERSION

>
= "#4"
This means that the requirement for this installation is that IIS must be equal to or greater than version 4.
If it is not, the installation fails. If the IIS version is 4, 5, or 6, the installation can proceed. You can feel
free to change this value to whatever you deem necessary. You can change the value to
IISVERSION
>
=
"#5"
, for example, to ensure it is either IIS 5.0, 6.0, or 7.0 at a minimum.
Another example of fine-tuning these launch conditions is the .NET Framework condition that enables
you to set the minimum version of the .NET Framework you want to allow. You do this by setting the
Version
property of the condition.
Summary
As you can see, you have many possibilities for installing your ASP.NET applications! From the simplest
mode of just copying the files to a remote server — sort of a save-and-run mode — to building a complex
1565