Deploy Windows Applications with Visual Studio.NET

http://www.codeguru.com/csharp/.net/net_vs_addins/visualstudioadd-ins/article.php/c7245
In the early days of personal computing, constructing an application that could be installed successfully on another computer was often as simple as compiling an .exe file and copying it to a floppy disk. As applications have become increasingly complex and sophisticated, the number of files needed for a typical installation has grown from a handful of files to several hundreds.

This is especially true with Windows applications, which have historically required sophisticated setup programs to copy the correct dynamic link libraries (DLLs) and support files to the end user's computer and to register the applications appropriately with the operating system. This first of a two-article series discusses the features provided by the .NET Framework for deploying Windows applications onto the end user's machine. To this end, it discusses the different types of deployment options the .NET Framework provides. It also takes a look at the architecture of the Windows Installer and then goes on to discuss the differences between XCOPY and Windows Installer. Along the way, it demonstrates the process of packaging up Windows forms applications using the setup and deployment project types supported by Visual Studio.NET.

Setup Versus Deployment

Before you can understand the processes involved in setting up and deploying applications, you need to understand the difference between setup and deployment. A setup is an application or process that allows you to package up your application into an easy-to-deploy format, which then can be used to install the application on another machine. Deployment is the process of taking the application and installing it in on another machine, usually by using a setup application.

Planning for Deployment

At one time or another, most computer users have experienced the dark side of installing Windows programs. For example, in the pre-.NET era, when you installed a new version of your Windows application, the installation program copied the new version of your DLLs into the system directory and made all the necessary Registry changes. This installation could impact other applications running on the machine, especially if an existing application was using the shared version of the installed component. If the installed component was backward compatible with the previous versions, then it was fine. In many cases, however, backward compatibility may be impossible to maintain. If you cannot maintain backward compatibility, you often end up breaking the existing applications as a result of new installations.

One of the areas Visual Studio .NET was designed to address was the installation shortcomings of Windows applications that relied heavily on COM components. Visual Studio .NET can simplify the installation process because Visual Studio .NET applications rely on .NET assemblies (which are built on a completely different programming model) for much of their functionality. In addition, Visual Studio .NET applications compile as assemblies, a deployment unit consisting of one or more files.

• Post a comment
• Email Article
• Print Article
•  Share Articles

To fully understand how Visual Studio .NET simplifies the deployment process, take a brief look at the structure of the assembly that provides for this simplification. Assemblies contain four elements:

• MSIL (Microsoft Intermediate Language) code—Language code (C#, VB.NET, and others) is compiled into this intermediate common language that can be understand by the common language runtime (CLR).
• Metadata—Contains information about the types, methods, and other elements defined in the code
• Manifest—Contains name and version information, a list of included files in the assembly, security information, and so on
• Non-executable content, such as supporting files and resources

As you can see, assemblies are so comprehensive and self-describing that Visual Studio .NET applications don't need to be registered with the Registry. This means that Visual Studio .NET applications can be installed by simply copying the required files to the target machine that has the .NET Framework installed. This is called XCOPY installation. However, it is also possible to automate the setup process by making use of the deployment projects that Visual Studio .NET provides. The next section examines Visual Studio .NET's various deployment options.

.NET Deployment Options

You can deploy Windows forms applications using any one of the following two deployment options:

• XCOPY deployment
• Deployment using Visual Studio .NET Installer

The following sections discuss both these deployment options and explains when to use each.

Using XCOPY for Deploying Applications

The .NET framework simplifies deployment by enabling XCOPY deployment. Prior to .NET, installing a component required copying the component to the appropriate directories and making the appropriate Registry entries. But with XCOPY deployment, all you have to do to install the component is copy the assembly into the bin directory of the client application. The application will be able to start using it right away because of the self-describing nature of the assembly. This is possible because compilers in the .NET framework embed identifiers or metadata into compiled modules, and the CLR uses this information to load the appropriate version of the assemblies. The identifiers contain all the information required to load and run modules and to locate all the other modules referenced by the assembly.

An XCOPY deployment is also called a zero-impact install because the way you configure the Registry entries and the component does not impact the machine. This zero-impact installation also makes it possible to uninstall a component without affecting the system in any manner. All you need to do is remove the specific files from the specific directory.

Using Visual Studio .NET Installer for Deploying Applications

Even though XCOPY deployment is very easy to use, it does not lend itself well to all deployment requirements. For example, if your application has more robust setup and deployment requirements, Visual Studio .NET Installer is a better option. Because Visual Studio .NET Installer is built on top of Windows Installer technology, it takes advantage of Windows Installer's features. To learn about Visual Studio .NET Installer, look first at the architecture of Windows Installer.

Windows Installer Architecture

Windows Installer is a software installation and configuration service that ships with the Windows 2000 and Windows XP operating systems. It also is freely available to all Win9x and NT4 platforms. Windows Installer Service maintains a record of information about every application that it installs. The Windows Installer runtime (MSI) inspects these records during the execution of deployment packages. When you uninstall an application, Windows Installer checks the records to make sure that no other applications rely on its components before removing it.

Windows Installer divides applications into the following three categories:

• Product—A product is something a user can install. For example, MS Word is a product.
• Feature—A feature is the smallest unit of functionality in a product. A product is composed of multiple features. For example, the AutoCorrect functionality can be considered a feature of MS Word.
• Component—A component is the smallest unit that multiple features can share. A component in Windows Installer terms is not the same as a component in the .NET Framework. A Windows Installer component can be a single file or multiple files that logically belong together. It can be an executable, a DLL, or a simple text file. A collection of components can join together to provide a feature, and a component also can be shared across multiple features. Whereas features are specific to a product and identified by a name unique only within the product, components are global across all products installed on a machine. For example, the spell checker component of MS Word can be shared across all the applications that want to implement spell-checking.

Information related to a product, such as features and components, are described in a centralized repository known as the Installation Database. The Installation Database is nothing but a file with the extension .msi that not only contains information about the features and components of the product but also about the sequence of user interfaces displayed during the installation of the product. Because the Windows Installer is registered as the default application for files with an .msi extension, the shell automatically invokes it when a user opens an .msi file. When invoked in this way, the installer reads product information from the Installation Database file and determines whether the product is already installed. If the product is not yet installed, it launches the product's installation sequence, which is described in the database. If the product is installed, different logic is invoked, such as adding and removing features or uninstalling the product.

Additional Visual Studio .NET Features

In addition to the Windows Installer, the deployment projects in Visual Studio .NET also provide the following features:

• Reading or writing of Registry keys
• Enables creating directories in the Windows file system
• Provides a mechanism to register both COM components and .NET components (in the GAC)
• Gathers information from the users during installation
• Enables setting launch conditions, such as checking the user name, computer name, current operating system, software application installed, presence of .NET CLR, and so forth
• Enables running a custom setup program or script after installation

You will take an in-depth look at all the above-mentioned features when you create deployment projects using Visual Studio .NET in an upcoming section of this article.

Trade Offs Between XCOPY and Windows Installer

As you can see, XCOPY is ideal for deployment scenarios that are simple and manually executed. However, many scenarios require a more robust deployment solution. In those cases, you should use the Windows Installer technology to install applications. The following advantages make Windows Installer ideal for creating setups and deployments for .NET applications:

• If an application installed with Windows Installer gets corrupted, it can perform a self-repair using the repair feature of Windows Installer packages. In XCOPY-based deployments, you need to manually replace the corrupted component with the newer version.
• The automatic rollback feature not only ensures that the installed components are uninstalled but also brings the machine back to the stage it was prior to the installer starting, if the installation fails.
• Because Windows Installer uses an MSI installation database for storing all the information, you can get the information about which files are copied, which Registry keys are created, and so on.
• If you're developing an application that you want to distribute to multiple users (or sell as a package), you can automate the entire installation process using Windows Installer's sophisticated installer technology—thereby simplifying the deployment.

Visual Studio .NET Deployment Project Templates

Visual Studio .NET comes bundled with five types of project templates that you can use to set up and deploy .NET applications. You can access these project templates the same way you would any other project in Visual Studio .NET, by using the File | New Project dialog box.

(Full Size Image)

Figure 1: Setup and Deployment Project Types Available in Visual Studio .NET

Figure 1 shows the different setup and deployment project types available in Visual Studio .NET. Take a brief look at each of the available project types:

• Setup Project template—Use the Setup Project template to create a standard Windows Installer setup for a Visual Studio .NET application.
• Web Setup Project template—Use the Web Setup Project template to create a Windows Installer setup program that can be used to install a Web application onto a virtual directory of a Web server.
• Merge Module Project template—Merge modules enable a set of files to be packaged up into an easy-to-use file that can be re-used and shared between setup programs that are based on Windows Installer technology. The idea is to package all the files and any other resources that are dependent on each other into the merge module. As you can imagine, this type of project can be very useful for packaging a component and all its dependencies into a single unit, which then can be merged into the setup program of each application that uses the component. During the installation, the merge module component is installed only if the component is not present on the machine. The merge module Windows installer package files are identified by the file extension .msm. For example, the latest versions of MSXML (Microsoft XML) Parser are also available in the form merge modules. If your application uses MSXML Parser, you can easily package the merge module into the setup program of your application.
• Setup Wizard template—Use the Setup Wizard to guide you through the process of creating one of the above setup and deployment project templates.
• Cab Project template—You use the Cab Project template to create a cabinet file (.cab). A cabinet file can contain any number of files, but no installation logic. It is generally used to package components into a single file, which can then be deployed on a Web server to enable the browser-based clients to download these components onto their local machines before installing them. For example, controls hosted on a Web page are often packaged up into a cabinet file and placed on the Web server. When the browser encounters the control, it verifies that the control isn't already installed in the local computer, at which point it downloads the cabinet file, extracts the control from it, and installs it onto the user's computer.

Creating an Installer Package

Now that you know the different setup project types, you can learn the steps involved in creating a setup and deployment project for a Windows application. During this example, you will create a simple Windows application and see how to deploy it. The application, named FormattingApplication, simply allows you to format the contents entered in a rich textbox. Because the main focus of this article is on creating Windows Installer packages, you will not spend too much time on this. However, you should download the source code for this project along with the support material on the final page of this article.

Start by adding a Windows Installer project to the solution that contains the C# formatting application project. Now, add a setup project to your existing solution by selecting File-> Add Project-> New Project from the New Project dialog box. Name the project FormattingApplicationSetup.

Configuring Deployment Properties

Now that you've created the project, you can configure its deployment-related properties. Right click on the FormattingApplicationSetup project from the Solution Explorer and select Properties. Then, open the Configuration Properties tree view and select Build. Click the Configuration Managercommand button to bring up the Configuration Manager dialog box. Now, change the Active Solution Configuration setting from Debug to Release for both the projects to create a Release build. Also, check the Build option for the setup project. By setting the configuration settings to Release, you create a release build that can be installed onto the end user's computer.

When you work with a VS.NET project, by default, you create a Debug build that creates the debugging information as part of the project output. The project output also is also not optimized for performance. Before deploying the application, change the Debug build to Release, which not only optimizes the project output for performance but also ignores the unnecessary debugging information.

After modification, the dialog box should look like Figure 2. Click Close.

Figure 2: Configuration Manager Dialog Box After Modification

The deployment project files can be packaged into any one of the following three formats:

• Loose uncompressed files—No compression takes place, and the entire program and data files are stored as they are.
• Setup file—When selected, this option merges all the files and compresses them into an MSI file.
• Cabinet file(s)—All files are packaged into one or more cabinet files. The MSI file contains entries about all the project .cab files, and it uses that information at runtime to load and install the .cab files. These files will be placed in the same directory as the MSI file.

In this case, because you want to compress all the files into a single MSI file, select the option In Setup file. Next, you need to configure the BootStrapper property. Set this property to Bootstrapper. A bootstrapper is a program that must be executed before the actual application can be run. When you install the application created with Visual Studio .NET Installer, it requires that Windows Installer version 1.5 be present on the target computer. The Windows XP operating system is the first operating system that comes bundled with Windows Installer 1.5. If you want to deploy your application on earlier systems, you need to include the bootstrapper as part of the installation program. If you include this option, it increases the file size by about 3MB. Because you want to include the bootstrapper to support earlier systems, you select that option.

If you are deploying your application only on Windows XP-based systems, you can safely ignore this option, thereby decreasing the size of the final installation program. If you use the Web Bootstrapper option, you need to make the bootstrapper available for download over the Web, as it isn't included in the MSI download. When selecting this option, you will be asked to provide the URL of the download. The user installing the application that installs the bootstrapper will use this URL. The main benefit to this approach is that no additional space is required in the installation package, which reduces the size of the install.

Finally, set the Compression property to Optimized for speed, which installs the files to be compressed faster.

Configuring Project Properties

Apart from setting the configuration properties for the entire solution, you also need to set the following deployment-specific properties for the deployment project, FormattingApplicationSetup. These properties are accessed through the Properties window. The following list discusses some of the important properties that can be set for a deployment project:

• AddRemoveProgramsIcon—Specifies the icon to be displayed in the Add/Remove Programs dialog box on the target computer
• Author—Allows you to specify the name of the application's author
• Description—Allows you to specify the description that is displayed during the installation
• Keywords—Specifies the keywords that can be used to search for an installer on the target machine
• DetectNewerInstalledVersion—Allows you to specify whether you want to check for newer versions of the application during the installation
• RemovePreviousVersions—Allows you to indicate whether you want to remove the previous versions of the application during the installation
• Manufacturer—Specifies the name of the application's manufacturer
• ManufacturerUrl—URL of the manufacturer's Web site
• ProductCode—Specifies a unique identifier (GUID) for the application
• ProductName—Name of the product
• SupportUrl—URL for the Web site that contains support information about the application
• Title—Title for the installer
• Version—Specifies the version number of the installer

After making the above changes, the FormattingApplicationSetup properties window looks like Figure 3.

Figure 3. FormattingApplicationSetup Properties Window After Configuration

Now that you understand the different properties that need to be configured, you can learn about the core component of setup and deployment projects that provides the foundation for performing advanced deployment-related configurations.

Different Types of Setup Editors

Because the deployment projects in Visual Studio .NET offer a great deal of flexibility, you very easily can specify how and where a solution will be deployed. Because the bulk of an installer's work is copying files to the right places, the setup editors obviously each contain a file system configuration editor. However, a setup also can include Registry configuration options, checking for special conditions, and so on. The ability to customize the installer's user interface is also useful. For this reason, VS .NET includes a number of editors within the setup projects.

The following editors can all be accessed through the View | Editors menu:

• File System Editor—Adds files and shortcuts, such as Start menu items, to the installation package
• Registry Editor—Manipulate Registry entries on the target computer
• File Types Editor—Associates file extensions with applications; useful in cases when your application uses custom file extensions and you want to associate a specific application with that file extension
• User Interface Editor—Configures the dialogs that are shown during the installation
• Custom Actions Editor—Starts external programs during installs and uninstalls
• Launch Conditions Editor—Specifies the requirements for your application to be installed on the target computer

What You've Learned

Part 1 of this article series taught you the different ways of deploying a Windows application and then identified when to use which deployment option. It also demonstrated the configurations that are required before creating an installer package. To this end, you used the project properties of a Setup and Deployment project and saw how these properties play an important role in the creation of an installer package. Part 2 will explore the different types of editors provided by the deployment project and then demonstrate how to deploy the installer project onto the target machines.

Part 1 of this series explained the different ways of deploying a Windows application with the .NET Framework and identified when to use which deployment option. It also demonstrated the configurations that are required to create an installer package. Part 2 examines the different editors that Visual Studio.NET provides and identifies the steps involved in using them.

As Part 1 showed, you can access six types of editors in Visual Studio .NET deployment projects through the View | Editors menu. These types are as follows:

• File System Editor—Adds files and shortcuts, such as Start menu items, to the installation package.
• Registry Editor—Manipulates Registry entries on the target computer.
• File Types Editor—Associates file extensions with applications; useful when your application uses custom file extensions and you want to associate a specific application with that file extension.
• User Interface Editor—Configures the dialogs that are shown during the installation.
• Custom Actions Editor—Starts external programs during installs and uninstalls.
• Launch Conditions Editor—Specifies the requirements for your application to be installed on the target computer.

Editors in Visual Studio .NET Deployment Projects

The following section takes an in-depth look at each of these editors, beginning with the File System Editor.

File System Editor

As its name suggests, the File System Editor allows you to add project output files, assemblies, and other files to the deployment project. By using this editor, you also can specify the directory location where these files will be installed on the end user's computer. You can open the File System Editor by selecting View->Editor->File System. The menu looks like Figure 1.

(Full Size Image)

• Post a comment
• Email Article
• Print Article
•  Share Articles

Figure 1: File System Editor Menu

By using any of the pre-defined folders displayed in Figure 1, you can choose a destination folder on a target computer without even having to know the actual path to that folder. The installer determines it from the virtual path during installation. Take a brief look at each of the pre-defined folders and their purposes:

• Application Folder—Application Folder is normally represented by the path [ProgramFilesFolder][Manufacturer]\[ProductName]. On English systems, the [ProgramFilesFolder] folder resolves to [Drive Name]\Program Files by default. The Manufacturer and ProductName directories take their names from the settings that you defined while setting the project properties. End users also can override these settings while installing the application.
• Global Assembly Cache folder—This folder allows you to specify the assemblies that must be installed as shared assemblies on the target computer.
• User's Desktop—This folder acts as a placeholder for files and folders that should appear on the end user's desktop. The default location for this folder is [DriveName]\Documents and Settings\[UserName]\Desktop. The username represents the name of the user who performs the installation.
• User's Programs Menu—This folder acts as a placeholder for entries that should appear on the programs group of the user. The default location for this folder is [DriveName]\Documents and Settings\[UserName]\Start Menu\Programs. The username represents the name of the user who performs the installation.

Apart from these folders, you also can add custom folders to the File System Editor from a pre-defined list. To display the list of special folders, right-click the File System on the Target Machine folder from the File System Editor and select Add Special Folder from the context menu.

Add Items to Special Folders

By using the File System Editor, you can add any of the following items to the special folders:

• Folder—Allows you to create a folder on the target machine in the specified directory
• Project Output—Allows you to specify where the output of one or more projects (.dll or .exe files) in the solution will be deployed on a target computer; also adds all the dependencies to the folder
• File—Allows you to deploy loose (zero compression) files to a target computer; very useful for deploying help files such as Readme.txt
• Assembly—Allows you to specify the assemblies that need to be added; adds all the referenced assemblies as well

Now that you've seen the different editors, configure your deployment project using the File System Editor. The following steps will use the FormattingApplication from the previous article. The first step in creating a setup is specifying which files you want to copy to the target computer:

1. Add the primary output of the FormattingApplication to the installer using the Project | Add | Project Output menu. After selecting the Application Folder directory, select Primary Output in the Add Project Output Group dialog box. Pressing OK in the dialog box adds the primary output of the FormattingApplication project to the Application Folder of File System Editor. At the same time, it also adds the dependencies to the installer project.
2. The FormattingApplication requires the .NET runtime, which it automatically adds to the installer project. As a result, the merge module for the .NET runtime dotnetfxredist_x86_enu.msm becomes visible in the Solution Explorer. This merge module includes all files for the .NET runtime. If the .NET runtime is not already installed on the target system, it will be installed along with your application.
   This case requires that the .NET runtime be already present in the target machine. So, you'll exclude this file from the package. Select the file dotnetfxredist_x86_enu.msm and then set the Exclude property to true through its properties window.
3. Now, add the additional folders and files. Right-click on Application Folder in the File System Editor and select Add->Folder. Name the created folder Support. This folder serves as a placeholder where you'll store all the supporting files for the application.
4. Right-click on the Support folder and select Add | File, and then add the files readme.rtf, license.rtf, Readme.txt, and developer.bmp.
5. Readme.txt should be available as an individual file so the end user can read that information before the installation. Make it a loose file (uncompressed) in the installer package. Select Readme.txt from the Support folder and select View->Properties Window. Change the PackageAs property to vsdpaLoose. This new setting overrides the setting vsdpaDefault, which packages the overall application.
6. Add a provision that allows users to create a shortcut to the FormattingApplication in their desktops. As before, you'll need to add the shortcut to the User's Desktop folder. Right-click on Primary output from the FormattingApplication (Active) item in the Application folder and select Create Shortcut to Primary output from FormattingApplication (Active) from the context menu. Rename the shortcut Formatting Application. Drag and drop it in the User's Desktop folder. However, you want this shortcut to be installed only if the user wants to install it. Therefore, set the Condition property of the User's Desktop folder to SHORTCUTDEMO. This ensures that the shortcut will be installed only if this condition is set to true. Later in this article, you will create a dialog box where this property can be set.
7. Make the program available from the Start->Programs menu by adding a shortcut to the User's Program Menu folder. Create another shortcut as before, renaming it Formatting Application. Drag and drop this shortcut in the User's Program's Menu folder. This time, you want this shortcut always to install so don't alter the Condition property.

Registry Editor

The Registry Editor allows you to manage the Registry settings on the target computer where the application will be installed. By default, the Registry Editor displays the standard Windows Registry keys, such as HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS. By using the Registry Editor, you also can add custom Registry keys under any of the above keys. Selecting View->Editor->Registry from the menu displays the Registry Editor shown in Figure 2.

(Full Size Image)

Figure 2: Registry Editor

To add additional Registry information that your application requires at runtime, you can use either HKEY_LOCAL_MACHINE\Software\[Manufacturer] or HKEY_CURRENT_USER\Software\[Manufacturer]. Be sure to add the application-specific information under the value specified in the Manufacturer property.

File Types Editor

The File Types Editor allows you to set up file associations on the target computer by assigning an application to a file extension. Double-clicking the file in turn launches the correct application. Once the initial association is done, the extension and the file type description appear in the file types list in Windows Explorer. This is very useful if your application uses custom file types that require a separate external application to be launched. The following are important properties associated with the File Types Editor:

• Name—Specifies the name used in the File Types Editor to identify a particular file type
• Command—Sets the executable file that should be launched when the user opens a file with this type
• Description—Provides the description for the file type
• Extensions—Specifies the file extensions with which the executable should be registered
• Icon—Specifies an icon to be displayed for the file type
• MIME—Specifies one or more MIME types to be associated with the selected file type
• Verb—Specifies the verbs (such as open, edit, and play) that are used to invoke the selected action for the file type

Custom Actions Editor

The Custom Actions Editor allows you to link to another program that can be launched at the end of the application install. To create a custom action, you need to create a .dll or .exe file that performs the custom action and add it to the deployment project. The custom actions can be launched only at the end of the installation. Custom actions can be associated with any one of the following four installation outcomes:

• Install
• Commit
• Rollback
• Uninstall

For example, if you want to launch a specific external program after installing the application, you can accomplish this by associating that external program with the Install node.

Launch Conditions Editor

By using the Launch Conditions Editor, you can specify conditions that must be met in order for the setup to run. If the user tries to install the application on a system that does not meet the launch conditions, the setup will not run. While setting the launch condition, you also can specify that searches be performed on the target computer to determine the existence of items such as a particular file, Registry key, component, and so on.

This editor has two sections to specify the requirements:

• Search Target Machine—Allows you to specify the kind of search that needs to be performed on the target computer (may include search for a specific file, Registry key, and so on)
• Launch Conditions—Allows you to define the conditions that need to be met to before allowing the application setup to be launched (one is already defined for the setup application)

For example, by using the Launch Conditions Editor, you can configure any of the following conditions:

• File Launch—Searches for installed files on the target system
• Registry Launch—Searches for Registry keys before the start of the installation
• Windows installer launch—Searches for Windows Installer files
• .NET Framework launch—Checks for the .NET Framework on the target computer
• Internet Information Services launch—Check for the installed version of IIS

While adding the primary output of the FormattingApplication project to the installer, you excluded the .NET runtime file (dotnetfxredist_x86_enu.msm) from the installer package. Therefore, you will check for the existence of the .NET runtime on the target computer by using the .NET Framework launch condition. To do this, you need to perform the following steps:

1. Open the Launch Conditions Editor by selecting View | Editor | Launch Conditions.
2. Add a launch condition using the Action | Add .NET Framework Launch Conditionmenu. Set the Name property to CHECKDOTNETCONDITION.

Now that you have set this launch condition, if the user tries to run the installation without having the .NET Framework installed, the installation will not run.

User Interface Editor

As its name indicates, the User Interface Editor permits you to specify the sequence of user interface dialogs displayed during the application install on the target computer. (You will see an example of this later when you configure these dialog boxes.)

The User Interface Editor consists of two high-level installation modes:

• Install—The Install section lists all the dialog boxes that will be displayed when the end user runs the installer.
• Administrative Install—This section lists all the dialog boxes that will be displayed when a system administrator uploads the installer to a network location.
\

The pre-defined dialog boxes in the Install and Administrative Install sections can be further sub-divided into the following three categories:

• Start dialog boxes—Display before the installation begins
• Progress dialog box—Allows you to provide the users with feedback on the progress of the installation
• End dialog boxes—Informs user that the installation has successfully completed; can also be used to allow the user to look at the Readme file or launch the application

You can easily rearrange the dialog boxes by dragging and dropping them onto other locations. The above-mentioned default set of dialog boxes always shows up in the installation sequence of the application, even if you have not configured them.

Now that you have had a look at the dialog boxes, it's time to learn how to configure them for setting up your FormattingApplication. Here are the steps:

1. Select the Welcome dialog and then select the View | Properties window. Set the BannerBitmap property to developer.gif by clicking Browse... in the combo box and navigating to the Application Folder\Support (where you already placed all the support files). Also set theCopyrightWarning and WelcomeText properties to values that suit your requirements.
2. Because you want the logo bitmap to display on all the default dialogs, set the BannerBitMapproperty to developer.gif in the Installation Folder, Confirm Installation, Progress, and Finished dialog boxes as well.

Add Additional Custom Dialogs

In the previous section, you configured the properties of the default dialogs, which are very flexible and can form the core foundation for simple installations. However, sometimes you may want to customize the installation sequence to support your application's requirements. You can accomplish this by adding a new set of dialog boxes with the Add Dialog menu. Select Start from the User Interface Editor and then choose Action | Add Dialog menu. Figure 3 shows the Add Dialog window you will see. It will only contain the dialogs that you can add, so you may see a slightly different selection.

Figure 3: The Action | Add Dialog Menu in the User Interface Editor

You can choose the dialog box you want to add to your installation sequence from this menu. The following list briefly discusses these dialog boxes and the dialogs already present by default:

• Welcome—Allows you to display an introductory window that can display text information from CopyrightWarning and WelcomeText properties
• Customer Information—Allows you to display a window that requires customer information such as name, organization name, and so on; also can force the user to enter a serial number and perform simple validations
• License Agreement—Allows you to display licensing information that requires the users to agree to the licensing conditions; obtains licensing information from an external file, which is linked to this dialog through the LicenseFile property that can be assigned a Rich Text Format (.rtf) file
• Read Me—Displays information from the .rtf file specified by the ReadmeFile property
• Register User—Allows users to complete the installation by asking them to register the installation; displays a Register Now button that either launches an external executable or takes the users to a Web site. (You specify the information about the external application and the arguments to be passed to it through Executable and Arguments properties, respectively.)
• Splash—Displays the company logo (that you can set through the SplashBitmap property) at the beginning of the install

As you can see, the Windows Installer is very restricted. It doesn't allow you to design custom windows and add them to the deployment project. However, Windows Installer does define a standard approach for creating installers that are consistent and simple to use. In this section, you add some additional dialog boxes to your installation sequence by using the Add Dialog menu. Here are the required steps:

1. Select Start from the User Interface Editor and choose the Action | Add Dialog menu.
2. In the Add Dialog box, select the Checkboxes (A), License Agreement, Read Me, andSplash dialog boxes, and then add them to the Start sequence.
3. Drag and drop the dialog boxes into the proper sequence, as displayed in Figure 4.

Figure 4: The Proper Sequence for the Dialog Boxes
4. To have the developer.com logo display on all of these additional default dialogs, set the BannerBitMap property to developer.gif.
5. Select the License Agreement dialog box and view its properties window. Change theLicenseFile property to license.rtf.
6. Select the Read Me dialog box and select View | Properties Window to bring up its properties window. Change the ReadMeFile property to readme.rtf.
7. Use the Checkboxes (A) dialog box to ask the user whether the demo shortcut you placed in the User's Desktop folder should be installed or not. Modify the properties of this dialog box to match the Figure 5 screenshot.

Figure 5: Modified Properties of Checkboxes (A) Dialog Box
8. Remember to set the CheckBox1Property to SHORTCUTDEMO. This value is the same as the Condition property that you set for the User's Desktop folder in the File System Editor. If the user selects this checkbox during installation, the value of the SHORTCUTDEMO condition is set to true. As a result, the shortcut installs on the user's desktop. If the user does not select this checkbox, the SHORTCUTDEMO condition is set to false and the shortcut does not install. In the Figure 4 dialog, you also set the Visible property for the rest of the checkboxes to false to prevent them from being displayed.

Build the Installer Package

Now that you have configured all the editors and set all the options, you can build the installer project. Select Build | Build Solution from the menu to create the MSI installer package. Once the installer is successfully built, you will see the files shown in Figure 6 in the Release directory of your installer project directory.

(Full Size Image)

Figure 6: Files in the Release Directory of Your Installer Project Directory

The Readme.txt file appears as a single file because you set the PackageAs property to vsdpaLoose when you configured the File System Editor. In addition, you see two variants of Windows Installers: one version (InstMsiA.exe) for Windows 98/ME; another version (InstMsiW.exe) for Windows NT/2000/XP.

Install the FormattingApplication

To install the FormattingApplication, you can use either of the following options:

• Double-click on either the FormattingApplicationSetup.msi file or the Setup.exe file from Windows Explorer.
• Right-click on the FormattingApplication.msi file and then choose Install from the context menu.

Now, follow the steps for installing the FormattingApplication on the end user's computer. Start the installation by double-clicking the FormattingApplicationSetup.msi file from Windows Explorer. The following steps lead you through the installation:

1. Splash screen—The first dialog, appears after a popup window that states Preparing to install; displays the bitmap you specified using the SplashBitmap property.
2. Welcome dialog box—The next dialog; displays the developer.com logo because you set the BannerBitMap property to it.
3. Read me dialog box—Displays the contents of the readme.rtf file that you specified using the ReadMeFile property; also displays the developer.com logo.
4. License Agreement—Displays the contents of the license.rtf file that you specified using the LicenseFile property; also displays the developer.com logo. (The Next button in the dialog box is enabled only when the user selects the I Agree option, thereby making sure that the user agrees to the licensing terms and conditions.)
5. Shortcut checkbox dialog box—Asks the user whether he or she wants a shortcut to the application to be installed in his or her desktop. (When the user checks the checkbox, he or she sets the condition SHORTCUTDEMO to true, thereby installing a shortcut to the application on the desktop.)
6. Installation folder—Displays the path to the installation folder where the application will be installed; also provides the user with an option to change the installation folder, if required. (You also can specify whether you want to install the application only for yourself or make it available to everyone who will be using that computer. You can also find out how much disk space is required to install the application by clicking the Disk Cost button.)
7. Disk cost—Helps identify the suitable drive (that has enough space) in which the application can be installed; displays the amount of disk space required for installing the application, as well as the free space available in each drive.
8. Confirm Installation—Allows you to provide the final confirmation before the application install can proceed. (Clicking the Next button on this dialog box installs the application on the user's computer. Its progress is displayed in the Progress dialog box as a progress bar.)
9. Finished Installation—Once the installation is complete, you see the Installation Complete dialog box, which confirms that the installation has successfully completed.

Uninstalling and Repairing the Application

Now that you have successfully installed the application, consider the uninstall process, which is very simple. Just open up the Add/Remove Programs window on the end user's computer by going to Start | Control Panel, and then double-click the Add/Remove Programs icon. Now, all you have to do is click the Remove button and a confirmation dialog box (asking you to confirm the uninstall process) appears. If you click Yes, the uninstall process begins and the application is completely removed. You also can uninstall the application by right-clicking on the FormattingApplicationSetup.msi from Windows Explorer and selecting Uninstall from the context menu. When you right-click on the FormattingApplicationSetup.msi file, you also see the Repair option in the context menu, which is very useful when you accidentally delete any of the application-related files from the machine and need to bring the application back to its original state.

What You've Learned

In this article, you learned the different aspects of deploying a Windows forms application. The discussion began with an introduction to deployment and its fundamentals and then went on to cover the different types of deployments supported by .NET. Specifically, the article covered XCOPY deployment and Windows Installer-based deployment.

After considering both types, you learned why the features that Windows Installer offers make it the preferred choice. Then you walked through a complete Windows forms application deployment using the Visual Studio .NET installer, including customization with various editors, installation on an end user's computer, and the uninstall process.