Planning the Deployment of Project

XCOPY Deployment

XCOPY deployment is a simple and straightforward deployment scenario. The name is derived from the DOS XCOPY command, which copies the contents of a directory (including subdirectories) to a target directory. In certain circumstances, you can use this very simple method to deploy your applications.

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 is used to indicate that subdirectories are to be copied as well. For example, to copy the MyApplication directory (including all subdirectories) from drive D: to drive C:, the following command-line command is used:

XCOPY D:\MyApplication C:\MyApplication /s

Information about additional command-line flags that can be used with XCOPY can be obtained by typing HELP XCOPY at the command prompt.

XCOPY deployment requires that all of the files required by the application be located in the application directory. This includes the compiled EXE files, any required DLL files representing components or controls, any required resource files, and any other files that the application requires. A second requirement for XCOPY deployment is that the .NET Framework must be installed on the target machine.

Additionally, an application to be deployed in this manner cannot require any additional files or resources (such as databases or shared components) that are not known to already be installed on each and every client machine on which your program will be installed. Clearly then, the limitations for XCOPY deployment are severe. As a rule, you should only use XCOPY deployment 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

Verify that your application meets the requirements for XCOPY deployment.
Open the command window. To locate the command window in Microsoft Windows XP, click Start, All Programs, Accessories.

Run XCOPY from the command prompt, specifying the source and destination directories, and include any command-line flags. For example:

XCOPY D:\MyApplication C:\MyApplication /s

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 and can be configured 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 basic kinds of setup projects as they relate to Windows Forms: setup projects and merge module projects. Setup projects are used for deploying executable applications.

A compiled setup project will contain a setup application capable of installing your program to a target computer. A merge module, on the other hand, is used to deploy controls or components that do not exist as stand-alone applications and cannot be deployed directly. It is a redistributable package that can be merged with an existing setup project. It contains all of the appropriate information concerning how and where to install the assembly, but 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 can then 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 Wizard in the Templates window.

To create a setup project for your application with the Setup Project wizard
From the File menu, choose Add Project, New Project.
The Add New Project dialog box opens.

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

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.

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

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. In addition to the files you specified for inclusion, Visual Studio .NET automatically detects any dependencies the setup project might have and adds them to the Detected Dependencies folder.

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 will dramatically increase the size of your application.

You should only do so if the target machine for your application does not have the .NET Framework already installed.

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 file: the Windows Installer file (with an .msi extension), which contains all of 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 to install Windows Installer on target machines that do not have Windows Installer already installed. You can access the Build properties of your project by right-clicking your project in Solution Explorer and choosing Properties.

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 \., where is a subdirectory for the selected configuration located in the project directory. defaults to the name of the project, and 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, as all of 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 can be 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) 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. If this option is chosen, 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 of 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 allows you to specify whether or not to generate a boot-strapping application along with your setup project. A bootstrapping application is used to install Windows Installer 1.5 to the target machine before your application is installed. Windows Installer 1.5 is the default version of 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.

If you are planning to make your application downloadable from the Web, however, you should choose the Web Bootstrapper option. Choosing Web Bootstrapper will cause 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 has slightly different functionality than the Setup.exe produced when the Windows Installer Bootstrapper option is chosen. The Setup.exe file determines if Windows Installer is already installed on the target machine, and if not, 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 not available to you. 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. Choosing Optimized For Speed will apply compression to your project, but will optimize for a fast install, resulting in a larger setup project as well. If you choose Optimized For Size, the setup project will be the smallest possible size, but 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. This enables three properties relating to your Authenticode Signature that can be set. You can specify the folder for an Authenticode certificate that you can use to sign your files in the Certificate File box.

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 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

A distribution plan should ensure that your application is capable of deploying to the target computers. There are many options available when choosing a distribution plan for your application including distributing with removable media, distributing via a network share, or distributing by download from the Web.

Distribution via Removable Media

Removable media has been the traditional way of 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 and thus might not have enough capacity for many of the setup projects you might create. The capacity of CD-ROMs is considerably larger, but might still fall short for very 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.

To distribute your application via removable media

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.

Build your setup project

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 for your application. 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 where they can 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

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

Share a folder on the network server, and set any appropriate access restrictions.
Copy the project setup output files from the Build folder to the network share folder.

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.

To distribute your application via a network share using administrative installation

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

Share a folder on the network server, and set any appropriate access restrictions.
Open the command window.

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

Invoke administrative installation by using the following command:

msiexec.exe /A .msi

where is the name of your setup program.

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

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 copying 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 because Web Bootstrappers have built-in authentication.

To distribute your application via the Web

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 you plan to copy your setup application to. If desired, you can specify an additional URL for the bootstrapper program in the Windows Installer Upgrade Program URL property.

Build your setup project.

Copy the project setup output files from the Build folder to the virtual folder that will host your application.

Publish the URL to your intended audience.

RELATED POST

DAY 11 OOPS INTRODUCTION

DAY 12 POLYMORPHISM

DAY 13 INHERITANCE AND POLYMORPHISM

DAY 14 EBUGGING TOOLS IN DOT NET

DAY 15 DEBUG AND TRACE IN CLASSES

DAY 16 UNIT TEST PLAN

DAY 17 EXCEPTIONS IN VISUAL STUDIO

DAY 19 ADO.NET INTRODUCTION

DAY 20 DATA ACCESSING IN DOT NET

DAY 21 DATA BASE OBJECTS

No comments:

Post a Comment