Lesson 1: Planning the Deployment of Your Project

Lesson 1: Planning the Deployment of Your Project

For an application to be successful, it must reach the intended audience. Microsoft Visual Studio .NET provides many different options for deploying your project, from simple XCOPY deployment (copying a directory and its subdirectories) to fully configurable Microsoft Windows Installer options. In this lesson, you will learn how to choose the best deployment option for your project.

After this lesson, you will be able to

• Explain how to use XCOPY to deploy a Microsoft Windows Forms application

• Describe how to create and configure a setup project for your application using the Setup Project Wizard

• Explain how to plan a deployment from removable media

• Explain how to plan a deployment from a network share

• Explain how to plan a deployment from a Web server

Estimated lesson time: 45 minutes

Once an application has been developed, tested, and debugged, it is ready for deployment to client machines. The goal of a deployment is the simple and easy installation of application files and any other required files to a client machine. For simple programs, the Microsoft .NET Framework allows you to deploy your application by copying the application directory to the target machine. For more complex applications, Visual Studio .NET provides Windows Installer technology, which allows you to make fully configurable setup projects for your application.

XCOPY Deployment

XCOPY deployment is a simple and straightforward deployment scenario that uses the MS-DOS XCOPY command to copy the contents of a directory and subdirectories to a target directory. XCOPY deployments have severe limitations, however.

XCOPY deployment is accomplished from the command prompt. You use the XCOPY command to specify the source directory and the target directory. The /s flag indicates that subdirectories are to be copied as well. For example, the following command-line command is used to copy the MyApplication directory and all subdirectories from drive D to drive C:

XCOPY D:\MyApplication C:\MyApplication /s

You can obtain information about additional XCOPY command-line flags by typing HELP XCOPY at the command prompt.

XCOPY deployment dictates that all files required by the application are located in the application directory. This includes the compiled .exe files and any other required files, such as .dll files representing components or controls and resource files. XCOPY deployment also requires installation of the .NET Framework on the target machine. Additionally, an application to be deployed in this manner cannot require any files or resources, such as databases or shared components, that are not already installed on each and every client machine on which the program will be installed.

As a rule, you should use XCOPY deployment only for applications that have no external dependencies outside of the .NET Framework and only if the .NET Framework is guaranteed to be installed on every target machine.

To deploy your application using XCOPY

1. Verify that your application meets the requirements for XCOPY deployment.

2. Open the command window. To locate the command window in Microsoft Windows XP, click Start, All Programs, Accessories.

3. Run XCOPY from the command prompt, specifying the source and destination directories and including any command-line flags, such as the /s example cited previously.

Creating Setup Projects

For applications that cannot be deployed by XCOPY, you can use Visual Studio .NET to create Windows Installer setup projects. Windows Installer projects are fully configurable for a variety of deployment plans. You can create a setup project for your application by adding a setup project to an existing solution.

There are two kinds of setup projects related to Windows Forms: setup projects and merge module projects. Setup projects are used for deploying executable applications. A compiled setup project contains a setup application capable of installing your program to a target computer. A merge module, on the other hand, deploys controls or components that do not exist as stand-alone applications and cannot be deployed directly. A merge module is a redistributable package that can be merged with an existing setup project. It contains all the appropriate information concerning how and where to install the assembly, but it must be installed along with an application.

Using the Setup Project Wizard

To choose the appropriate type of setup application for your project, Visual Studio .NET provides the Setup Project Wizard. The Setup Project Wizard walks you through the task of creating your setup project and quickly creates the base setup project, which then can be further configured in the integrated development environment (IDE).

To add a setup project to your solution, click File, Add Project, New Project to display the Add New Project dialog box. To access the Setup Project Wizard, choose Setup And Deployment Projects in the Project Types pane and Setup Project Wizard in the Templates window. This launches the Setup Project Wizard shown in Figure 10.1.

Figure 10-1. The Setup Project Wizard.

Click Next to open the Choose A Project Type page, as shown in Figure 10.2. This page allows you to specify the type of setup project to create. If you are creating a setup project for an application, choose Create A Setup For A Windows Application. If you are creating a setup project for a DLL file (in other words, a nonexecutable assembly), choose Create A Merge Module For Windows Installer. Click Next.

Figure 10-2. Choosing the project type in the Setup Wizard.

The Choose Project Outputs To Include page allows you to choose the files from your solution that will be included in your setup project. Normally, you will see five check boxes (six for Visual C#) for each project in your solution, each of which specifies a type of content to be added to the setup project. As each entry is clicked, a description of that entry is shown in the Description box. The Visual Basic .NET page is shown in Figure 10.3.

Figure 10-3. Using the Setup Wizard to choose project outputs to include in your setup project.

Select the Primary Output check box if you want to include the .exe or .dll files represented by the project. Source Files and Debug Symbols can be useful in a test deployment but are usually not needed for a release deployment. Click Next.

Figure 10.4 shows the Choose Files To Include page of the Setup Project Wizard. This page allows you to specify additional files to be included in your setup project. Additional files can be text files that consist of readme information, HTML pages containing application help, or other kinds of support files that normally are not included with the application. You can specify a file by clicking the Add button and browsing to the appropriate file. Click Next.

Figure 10-4. Using the Setup Wizard to choose other files to include in your setup project.

The Create Project page of the Setup Project Wizard, shown in Figure 10.5, provides a detailed summary of your choices for the setup project. Click Finish to create the setup project and add it to your solution. At any time after it is created, you can add additional content to your setup project by right-clicking the project in Solution Explorer and choosing the appropriate option from the Add menu.

Figure 10-5. The Setup Project Wizard summary.

To create a setup project for your application with the Setup Project Wizard

1. From the File menu, choose Add Project, New Project. The Add New Project dialog box opens.

2. In the Project Types pane, choose Setup And Deployment Projects. In the Templates pane, choose Setup Wizard.

3. After the title pane, choose the type of setup project. Choose Merge Module for a DLL or Setup For A Windows Application for an application.

4. Use the next two screens to specify the project output and any additional files that you want to include in your setup project.

5. On the Summary screen, click Finish to create your setup project.

Once you create your setup project, it is added to your solution and can be viewed in Solution Explorer, as shown in Figure 10.6. In addition to the files you specify for inclusion, Visual Studio .NET automatically detects any dependencies the setup project might have and adds them to the Detected Dependencies folder. For example, in Figure 10.6, a dependency on the .NET Framework redistributable package has been detected. Dependencies that are not explicitly included in the setup project are excluded from the build process by default. You can include an excluded dependency file by right-clicking the file in Solution Explorer and clearing the check mark from Exclude in the pop-up menu. Note that including the .NET Framework redistributable files dramatically increases the size of your application. You should only include redistributable files if the target machine for your application does not have the .NET Framework already installed.

Figure 10-6. A detected dependency.

Configuring Build Properties of Your Setup Project

Once your setup project has been added to your solution, you can configure the output it produces by setting the Build properties. Normally, a setup project produces at least one Windows Installer file (with an .msi extension), which contains all the information and content needed to install your application to a target computer. Depending on how the Build properties are configured, however, you can create additional files to package content or install Windows Installer on target machines that do not have it already. You can access the Build properties of your project by right-clicking your project in Solution Explorer and choosing Properties. This displays the Property Pages dialog box for your setup application. An example is shown in Figure 10.7.

Figure 10-7. The Setup Property Pages dialog box.

The Build properties determine how the output of your setup project is configured. You might want to provide different values for these properties based on the deployment plan for your project. The Build properties are discussed in detail in the following sections. Refer to Figure 10.7 throughout this discussion.

Output File Name

The Output File Name option represents the location where the Windows Installer file will be placed when built and the name it will have. The default value for this property is <configuration>\<project name>.<extension>, where <configuration> is a subdirectory for the selected configuration located in the project directory, <project name> defaults to the name of the project, and <extension> is .msi for Windows Installer applications and .msm for Windows Installer merge modules. You can alter the build path by clicking the Browse button and choosing a new build directory.

Package Files

The Package Files option determines how the output files for your solution will be packaged into the setup project. The default setting is to package output files in the setup file itself. This allows for the greatest level of compression and the lowest level of complexity because all the information needed to deploy your application is contained within a single file.

In some cases, however, you might want to package your application in Cabinet (CAB) files. When you package your output into CAB files, you can choose the size of the CAB files you produce. This is useful if you have a size limitation for your output files. For example, if you plan to distribute your application on floppy disks, you would want to package your output files into CAB files and set the CAB file size (see the next section for more information) to 1440 KB. You could then copy the resulting CAB files to floppy disks.

Another option for this property is to package your output in loose, uncompressed files. With this option, no compression is applied, and the project output files are simply copied to the same directory as the .msi file.

CAB Size

If you choose to package your files in CAB files, the CAB Size property becomes enabled. You can choose between two options for this property. Choosing Unlimited causes the setup project to create a single CAB file that contains all your project output. If you choose Custom, you can specify the maximum size of your CAB files. This is particularly useful if you are planning to distribute your application on floppy disks or other removable media.

Bootstrapper

The Bootstrapper option for your setup project allows you to specify whether to generate a bootstrapping application along with your setup project. A bootstrapping application installs Windows Installer 1.5 to the target machine before your application is installed. Windows Installer 1.5 is the default version of Windows Installer for Windows XP. If you choose to create a bootstrapping application, your setup project will generate additional files that will be used by your setup application to install Windows Installer 1.5 when necessary. Any deployment to Windows XP will not require the use of a bootstrapping application. If you are deploying to a prior version of Windows, you will need to run the bootstrapping application the first time a Windows Installer project is used.

If you are only planning to deploy your application to machines running Windows XP or machines that have already had Windows Installer 1.5 installed, you can choose None to generate no bootstrapping application. Otherwise, you would choose Windows Installer Bootstrapper for most distribution plans. Choosing Windows Installer causes four additional files to be generated and placed in the Build directory. These files are summarized in Table 10.1.

Table 10-1. Windows Installer Bootstrapper Files

File	Description
Setup.exe	This file serves as the entry point for the installation process. When this application is run, it checks to see if the target machine already has Windows Installer 1.5 installed. If not, it invokes InstMsiA.exe or InstMsiW.exe as appropriate to install Windows Installer. It then installs the application from the MSI file.
InstMsiA.exe	Installs Windows Installer 1.5 on a Windows 95 or Windows 98 machine.
InstMsiW.exe	Installs Windows Installer 1.5 on a Windows NT or Windows 2000 machine.
Setup.ini	Contains the name of the .msi file to be run by Setup.exe after installation of Windows Installer is verified.

If you plan to make your application downloadable from the Web, however, you should choose the Web Bootstrapper option for your setup project. Choosing Web Bootstrapper causes three additional files to be generated and placed in your output folder. The InstMsiA.exe and InstMsiW.exe files function in the same manner as was described for the Windows Installer Bootstrapper option: they install Windows Installer to the machine as appropriate. The third file is also called Setup.exe, but it has slightly different functionality than the Setup.exe produced with the Windows Installer Bootstrapper option. The Setup.exe file determines if Windows Installer is already installed on the target machine, and if not, it downloads the appropriate executable to install it. Then it downloads and executes the .msi file containing your application.

Choosing the Web Bootstrapper option opens the Web Bootstrapper Settings dialog box, which allows you to set two additional properties. The Setup Folder URL specifies the Web folder that contains the setup installer program and any files associated with that program. You can specify a different URL for the Web Bootstrapper files (InstMsiA.exe and InstMsiW.exe) by setting the Windows Installer Upgrade Folder URL. This allows you to put the bootstrapping application in a different Web folder than the setup application. If you do not specify a different folder, the Web Bootstrapper executable files should be installed to the same Web folder as the setup files.

Compression

The Compression property determines which compression scheme will be applied to the setup project. If you chose to package your files as loose, uncompressed files, this option is unavailable. Otherwise, you can choose between three settings. None indicates that no compression will be applied to the files. This generally results in the fastest install time but can dramatically increase the size of your setup project. Optimized For Speed applies compression to your project but will optimize for a fast install, resulting in a larger setup project as well. Optimized For Size results in a setup project of the smallest possible size, but it might require more time to install.

Authenticode Signature

If you want to use Authenticode signing to sign your setup project, select the check box next to Authenticode Signature in the Setup Property Pages dialog box. This enables three properties relating to your Authenticode signature that can be set. The Certificate File box allows you to specify the folder that contains an Authenticode certificate, which can be used to sign your files. The Browse button allows you to browse to the folder containing the certificate. Similarly, in the Private Key File box, you can specify the folder that contains the private key for digital encryption of the signed files, and you can use the Browse button to browse to the appropriate folder. Additionally, the Timestamp Server URL box lets you specify the Web location for a timestamp server used to sign the files. If you specify Authenticode Signature, you must specify a folder for your certificate file and your private key. Specifying a Timestamp Server URL is optional.

Building, Distributing, and Deploying a Setup Project

Once you have specified the output to be included in your setup project and have set the relevant properties, you can build and distribute it. Once distributed, your setup project can be deployed to client machines.

Building the Project

To build the setup project, select the project in Solution Explorer and choose Build <project name> from the Build menu. This invokes the build process for your setup project. The resultant files from the setup build are located in the folder specified by Output File Name in the Setup Property Pages. These files can then be copied to the distribution platform you have chosen.

Distributing the Setup Project

Your distribution plan should ensure that your application is capable of deploying to the target computers. The many options for distributing your application include distributing with removable media, distributing via a network share, or distributing by download from the Web.

Distribution via Removable Media

Removable media is the traditional method for distributing applications. When planning a distribution with removable media, it is important to keep the capacity of the chosen medium in mind. Floppy disks have a maximum capacity of 1.44 MB, so they might not have enough capacity for many setup projects. The capacity of a CD-ROM is considerably larger, but it still might fall short for large setup projects. If your setup application needs to be larger than the capacity of your chosen medium, package your output files in CAB files and copy the resultant CAB files to multiple disks or to a DVD.

To distribute your application via removable media

1. Analyze the size requirements for your setup project, and choose how the files will be packaged on the Property Pages for your application. If you are planning a distribution via floppy disks, choose CAB files and set the CAB file maximum size to 1440 KB.

2. Build your setup project.

3. Copy the setup project output files from the Build folder to the removable media. If you are distributing via floppy disks and have created multiple CAB files, copy the .msi file to the first disk and then copy each CAB file to a separate disk.

Distribution via a Network Share

If your application is designed for use by a group of users on a common network, you can distribute your application by placing it on a network share. In general, this is the simplest method of distribution. All you need to do to distribute your application via a network share is share a folder on the network server and copy the output files to the shared folder. You can then publish the address of the network share to your intended users, who can then download the installation files to the target machines. Additionally, the network administrator can set security properties for the network share folder so that only the intended recipients of the application can download the installer files. If a bootstrapper application is to be included with the setup project, choose a Windows Installer Bootstrapper on the Property Pages.

To distribute your application via a network share

1. If you are including a bootstrapper application with your setup project, choose Windows Installer Bootstrapper on the Property Pages for your setup project.

2. Build your setup project.

3. Share a folder on the network server, and set any appropriate access restrictions.

4. Copy the project setup output files from the Build folder to the network share folder.

5. Publish the network address of the setup files to the end users.

Distribution via a Network Share Using Administrative Installation

You can also deploy your application to a network share via administrative installation. This allows you to create an image of the application and the setup file in a shared folder. End users can then download the setup file from the share and install it on their own machines. Administrative installation allows you greater flexibility in configuring the installation properties for the application on the target computers. As you will see in Lesson 2, during administrative installation, you can set options for your application that are then carried over to the client installations.

To distribute your application via a network share using administrative installation

1. If you are including a bootstrapper application with your setup project, choose Windows Installer Bootstrapper on the Property Pages for your setup project.

2. Build your setup project.

3. Share a folder on the network server, and set any appropriate access restrictions.

4. Open the command window.

5. Change the directory in the command window to the directory that contains the setup project.

6. Invoke administrative installation by using the following command, where <setup> is the name of your setup program:

   msiexec.exe /A <setup>.msi

7. Follow the instructions given by the Setup Project Wizard. Choose the shared folder as the target folder for installation.

8. Publish the network address of the setup files to the end users.

Distribution via the World Wide Web

For a project with a wide distribution audience, you might want to distribute your application via an Internet download. The procedure for making your application accessible over the Internet is fundamentally the same as distributing via a network share. Rather than copy your installer files to a shared directory, however, you copy them to a virtual Web directory. If you are including a bootstrapper application with your setup project, you can copy the bootstrapper application to another directory, as specified by the Windows Installer Upgrade Folder URL setting on the Property Pages. If you are including a bootstrapper, set the Bootstrapper property to Web Bootstrapper for built-in authentication.

To distribute your application via the Web

1. If you are including a bootstrapper application with your setup project, choose Web Bootstrapper on the Property Pages for your setup project. Set the Setup Folder URL property to the URL to which you plan to copy your setup application. If desired, you can specify an additional URL for the bootstrapper program in the Windows Installer Upgrade Folder URL property.

2. Build your setup project.

3. Copy the project setup output files from the Build folder to the virtual folder that will host your application. If you specified a Setup Folder URL property for a Web Bootstrapper in Step 1, you should copy the output files to the folder represented by that URL.

4. Publish the URL to your intended audience.

Deploying Your Project

Once the setup program has been created and distributed, deploying an application is an easy process. If you chose not to create a bootstrapper application, you simply double-click on the .msi file created by your setup project. If a bootstrapper application is included, you can launch the process by double-clicking the Setup.exe file, which will install Windows Installer if necessary. Either approach ultimately will open the .msi file created by your setup project, which will launch the Setup Wizard. The wizard will automatically install your application to the correct directories. In Lesson 2 of this chapter, you will learn to configure the Setup Wizard to create seamless installations.

Lesson Summary

• Under rare conditions, you can deploy a .NET application by using XCOPY to copy the application directory and all subdirectories to a target computer. This is possible only when the .NET Framework is installed on all target machines and the application has no dependencies on shared assemblies or resources. In most circumstances, XCOPY deployment is not a viable possibility.

• You can use Visual Studio .NET to create Windows Installer setup projects and merge modules. A setup project must be executed on a computer that has Windows Installer 1.5 installed and contains all the content and information needed to install an application to a client computer. A merge module is used to package DLL files and cannot be installed by itself it must be merged with a setup project.

• The Setup Project Wizard allows you to specify the content to add to your setup project and choose the kind of setup project to create.

• You can configure the Build properties of your setup project by using the Setup Property Pages. You can configure how the files are packaged, compression settings, whether to create a bootstrapper, the output file directory, and Authenticode settings.

• Once the project is built, you can distribute it in a variety of ways. You should configure the Build properties of your setup project to be optimized for your distribution plan.