第 140 页

information, getting started samples, or documentation and README fi les.

fiGure 48 - 2

A merge module is a special type of installer that contains the instructions

for installing a shared component. Once a merge module has been created, it

can be included within a number of installers providing re - use and simplifi ed

maintenance. Merge modules must be included within an installer fi le. They

cannot be installed by themselves.

A CAB project produces a collection of .cab fi les, which contain a set of

compressed fi les. The .cab fi les can be downloaded individually or opened from

a number of disks. Typically, the contents of the .cab fi les are copied to the local

fi le system when the installer runs.

Occasionally you may choose to deploy debug symbols with your application,

because this can aid you in diagnosing a failing application in production.

However, it is not generally deemed a good practice to do this, because you should

incorporate suffi cient logging or other diagnostic instrumentation for this purpose.

Windows installers . 963

964 .

chaPter 48 pAckAging And deploymenT

Once the deployment project has been created, it is added to the

Solution Explorer, as shown in Figure 48-3 . Although you didn’t

explicitly add any files or output from the SharedResources

class library to the deployment project, it has been added as

a detected dependency. If the dependencies are guaranteed to

exist on the target computer, they can be manually excluded

from the deployment project by selecting the Exclude item from

the right-click context menu. For example, if this were an

add-in for another application that already has a copy of the

SharedResources assembly, you could exclude that from

the dependency list. The resulting installer would be smaller,

and thus easier to deploy.

fiGure 48-3

If the dependencies between your projects vary, it may be necessary to force

a recalculation of these dependencies. You can do this by selecting Refresh

Dependencies from the right - click shortcut menu on the Detected Dependencies

node.

When a deployment project

(DeploymentInstaller) is selected, a number

of new icons appear across the top of the

Solution Explorer window, as shown in

Figure 48-3 . Unlike other project types,

where the project properties appear in the

main editor area, clicking the first icon

(Properties) opens the Property Pages dialog,

as shown in Figure 48-4. This can be used

to customize how the deployment module is

built. This dialog can also be accessed via

the Properties item on the right-click context

menu for the deployment project in the

Solution Explorer.

By default, the Package Files property is set to “In setup file,” so all executables and associated

dependencies are placed into the .msi file that is created. The deployment project also creates

a Setup.exe file that checks for minimum requirements, such as the presence of the .NET

Framework, prior to calling the .msi file to install the application. Although the compression

can be adjusted to optimize for file size, including everything into a single distributable might be

an issue for large projects. An alternative, as shown in Figure 48-4, is to package the application

into a series of CAB files. In this scenario, the size of the CAB file is limited to 100Kb, which will

aid deployment over a slow network. Another scenario where this would be useful is if you were

planning to deploy your application via CD or DVD, and your application exceeded the capacity of

a single disc.

fiGure 48-4

Windows installers .

965

The final property on this page is the Installation URL. If you are planning to deploy your

application via a web site, you can elect to package everything into a single file, in which case

you do not need to specify the Installation URL, because you can simply add a reference to the

Setup.exe file to the appropriate web site and a user can install the application simply by clicking

the link. Alternatively, you can package your

application into smaller units that can be

incrementally downloaded. To do this, you

must specify the Installation URL from which

they will be installed.

As just discussed, the default deployment

project creates a Setup.exe file. The

Prerequisites button opens a dialog like

the one shown in Figure 48-5, where you

can configure the behavior of this file.

You can indicate that a setup file should

not be created, in which case the application

can be installed by double-clicking the .msi

file. This, of course, removes the initial check

to ensure that the .NET Framework has been

installed.

In addition to the .NET Framework, you can also

specify that other components, such as SQL Server

Compact 3.5, need to be installed. These checks will

be carried out, and the user prompted to install any

missing components before the main installer file

is invoked. Depending on how you want to deploy

your application, having all the prerequisites in the

same location as your application may be useful and

will eliminate time spent looking for the appropriate

download.

Returning to the Solution Explorer and your

DeploymentInstaller project (and just to confuse

matters), there is an additional Properties window

for deployment projects that can be opened by

selecting the appropriate project and pressing F4.

This opens the standard Properties window, shown

in Figure 48-6, which can be used to tailor the

deployment details for the application it is installing.

The properties for the deployment project shown

on this screen configure the appearance, icons, and

behavior of the installation wizard. It is highly

fiGure 48-5

fiGure 48-6

966 .

chaPter 48 pAckAging And deploymenT

recommended that you adjust these properties

so your application is easily identifi able in the

Add/Remove Programs dialog, and so that

the installation looks professional rather than

half - fi nished. As you can see from Figure 48 - 7 ,

some of these properties are used to tailor the

installer dialog.

Once the application has been installed, some of

these properties also appear in the Programs and

Features dialog (Add/Remove Programs under

Windows 7) accessible via the Control Panel,

as shown in Figure 48-8. Here you can see the

AddRemoveProgramsIcon, the ProductName,

and the Manufacturer properties. You can

display more properties by right-clicking the

header bar and selecting More.

fiGure 48-7

fiGure 48-8

In order to test your installer, you can select the Install (and subsequently

Uninstall) item from the shortcut menu that is displayed when you right-click the

setup Project in the Solution Explorer. If this option is disabled, you may need to

build the setup Project first.

customizing the installer

The remaining icons at the top of the Solution Explorer are used to customize what is included

in the deployment package. In addition to the shortcut icons, these views of the deployment project

can be accessed via the View item on the right-click context menu. Start with the File System view,

which indicates where files will be installed on the target machine. By default, the primary output

Windows installers .

967

for a Windows application is added to the Application Folder, as shown in Figure 48-9. Selecting

this node and looking at the Properties window shows that this folder has a default location of

[ProgramFilesFolder][Manufacturer]\[ProductName]. This location is made up of three

predefined installation variables: ProgramFilesFolder, Manufacturer, and ProductName, which

will be evaluated and combined during installation. As you can see in Figure 48-7, the installation

wizard allows users to change this location when they install the application.

Earlier, you saw that the CallCentre Application had a dependency on the SharedResources assembly.

In Figure 48-9 this assembly has been removed from the Application Folder and placed instead in

the Global Assembly Cache Folder. When this application is installed, the main executable will

be installed in the relevant directory under Program Files, but the SharedResources assembly

will be installed in the Global Assembly Cache so it is available to any .NET application. To

achieve this, you first need to create the new folder in the File System view by selecting the Global

Assembly Cache Folder from the Add Special Folder item on the right-click context menu. You can

install files to a number of other special folders as part of the installer. The next step is to move

the SharedResources assembly to the Global Assembly Cache by selecting the assembly in the right

pane of the File System view and changing the Folder property from Application Folder to Global

Assembly Cache Folder. Alternatively, you can drag the item from the Application Folder to the

Global Assembly Cache Folder.

fiGure 48-9

In addition to installing files on the target machine, you can also add keys to the registry. Some

developers argue for and other developers argue against the use of the registry. Although it can

provide a convenient store for per-user configuration information, the application settings with user

scope are an alternative that makes them easier to manage. The Registry view, as shown in Figure

48-10, can be used to add registry keys and values. To add a new key, right-click the appropriate

node in the Registry tree and select Add Key from the context menu. To add a new value, select the

appropriate key in the Registry tree and select the type of value from the New item on the right-click

context menu off the right pane shown in Figure 48-10. The Name and Value can then be set using

the Properties window.

Figure 48-11 shows the File Types view of the deployment project. This view is used to add file

extensions that should be installed. For example, in this case you are installing the extension .call.

You can specify an icon for this type of file, as well as specify the executable that should be called

for this file type. In most cases this will be the primary output for your application. To add a new

file type, right-click the root node of the File Types tree and select Add File Types from the context

menu. This creates a node for the new file type and for the default action (in bold) for that file type.

For the .call extension, the default action is Open, and it can be executed by double-clicking a file

of the appropriate file type. The Open action also appears, again in bold, in the right-click context

968 .

chaPter 48 pAckAging And deploymenT

menu for a file with the .call extension. You can add other actions for this file type by selecting

Add Action from the right-click context menu for the file type. An alternative action can be made

the default by selecting Set as Default from that action’s context menu. You can change the order in

which the actions appear in the context menu by moving the action up or down in the tree.

fiGure 48-10 fiGure 48-11

.NET applications can be autonomous so that their list of dependencies may only contain the .NET

Framework. However, web applications require IIS, and more complex applications may require SQL

Server to be installed. You can check for these dependencies by using a launch condition via the view

shown in Figure 48-12. By default, the .NET Framework is added to this launch condition. Previously

you saw that Setup.exe also did a check for the .NET Framework and would install it if it was not

found. Launch conditions are embedded in the .msi file and, unlike conditions in the Setup.exe

file,

are validated even if the .msi file is installed directly. The only limitation is that the launch conditions

only provide a warning message and a URL reference for more information. In the case of the .NET

framework launch condition, this message and URL are already provided for you.

fiGure 48-12

When the Setup.exe file checks for the .NET Framework it is limited to

searching for or installing a specific version. The .NET Framework launch

condition can be configured to detect a specific version as well, but if your

application is able to target multiple versions, you can instead set the Version

property of the launch condition to Any. This allows your application to be

deployed as long as there is any version of the .NET Framework installed.

The tree in the left pane of Figure 48-12 is actually split into two sections. The top half of the tree is

used to specify searches to be performed on the target machine. Searches can be carried out for files,

Windows installers .

969

for installed components or applications, and for registry values. Properties for a file search include

the search folder, version and modification dates, and file size. To search for an installed component,

you need to know the Component ID, which is embedded in the .msi file used to install the product.

This information can be retrieved using a product such as Orca, which is included in the Windows

SDK Components for Windows Installer Developers that you can download from the Microsoft web

site (www.microsoft.com/downloads/). A registry search requires properties indicating the key,

name, and value to search for. In each of these cases, the search needs to be assigned a Property

identifier. If the search is successful, the installer property with that identifier is True.

The Property identifiers assigned to searches on the target machine can be used by a launch

condition in the lower half of the tree. As you can see in Figure 48-12, there are conditions that

check for the .NET Framework, as well as a custom launch condition. The Condition property

is set to a logical AND operation across the three search results. If any of the searches fail, the

associated property identifier is replaced with False, making the whole logical expression false.

This will prevent the application from installing, and a warning message will be displayed.

Note that some other views have a Condition property for some of the tree nodes. For example,