Packaging a .NET Application for Deployment | MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework

‚ ‚

Packaging an application means identifying all the individual files and settings for an application and putting them together so that the application can be easily distributed and deployed on the target computers.

Different techniques are available to package an application for deployment. Choosing the right packaging technique is important because it not only eases the process of deployment, but also minimizes the total cost of ownership for the application's customers. The choice of packaging depends on the nature of the application and its users. For installing simple applications, sometimes a tool as simple as the XCOPY command can be used. For sophisticated requirements, you might want to use a tool that creates a Windows Installer ‚ based setup package for the application.

NOTE

Deploying Multitier Applications Distributed applications are often designed as n-tier applications. In that case, different tiers of the application are often deployed on separate computers for the sake of modularity. To increase reliability and performance, a single tier might also be sometimes installed on multiple computers working together in a Web Farm or cluster. Different tiers of an application are usually also different types of applications and have varied installation requirements.

For these reasons, it is hardly possible to devise a single mechanism for deploying the entire multitier application. The most common approach is to use a separate deployment mechanism for each tier of the application.

Packaging an Application for Deployment by Copying the Files

Applications developed using Microsoft .NET Framework do not generally use the Windows Registry for storing application-specific data and configuration settings. Instead, all settings are stored in XML-based configuration files.

It is possible to deploy such an application by copying all the build output and content files to a folder of your choice on the target computer. You can simply use the XCOPY command or use FTP if you are deploying across the Internet. When you need to uninstall an application, all you need to do is delete the folder that contains the application's files. Because the deployment process is nonintrusive and causes minimum changes on the target computer, it is also sometimes called zero-impact installation.

However, there are scenarios in which copying the files is not sufficient for deploying an application. Some common installation tasks that are difficult to do just by copying the files are as follows :

For a Web service and a Web application, you also need to create a virtual directory on the Web server, set the virtual directory as an IIS application, and possibly configure security or other settings for the virtual directory.
For a Windows Service, you need to register the service with the Windows Service Control Manager.
For a serviced component, you need to register the component with the COM+ catalog.
You might need to take extra steps to provide the application's integration with the user desktop such as creating shortcuts and Start menu entries.
You might need to add shared assemblies to the GAC.
You might need to allow users to select features during installation.
You might need to copy files to relative paths on the target machine that differ from the paths on the source machine.
You might need to create or configure databases during the installation.
You might need to add custom event logs and performance counters to the target machine.
You might need to check whether the .NET Framework is installed on the target machine.
You might need to present a user-friendly and branded user interface during the installation process.
You might need to do license key management and user registration as part of the installation.

Because of these limitations, you can generally use the XCOPY command only when the application is deployed by the system administrators or the application developers. This might be true for server-side applications because they are deployed only on a few servers and these servers are more likely to be closely administered.

On the other hand, if you are commercially distributing your application, in most cases you would want to package your application as a Windows Installer package.

Packaging an Application for Deployment Using Microsoft Windows Installer

The Microsoft Windows Installer is an installation and configuration service that is built in to the Windows operating system. It gives you complete control over the installation of an application, a component, or an update.

The Windows Installer includes many built-in actions for performing the installation process. In addition to performing the standard actions, such as installing files, creating shortcuts to files, making Start menu entries, and writing Registry entries, the Windows Installer also offers several advanced features; some of which are listed here:

It provides the ability to take custom actions during application installation. For example, you might want to run a SQL script to install an application database during application installation.
It provides on-demand installation of features. This capability allows the user to install, at a later stage, a feature that was not installed during the application's initial installation. On-demand installation does not force the user to reinstall the entire installation package; the user can just add a single feature.
It provides the ability to roll back an installation. The Windows Installer maintains an undo operation for every operation that is performed during an application installation. If the Windows Installer encounters any errors while installing an application, it can uninstall everything that was installed during the installation.
It allows you to uninstall an application without breaking any other application that depends on it.
It allows you to fix an application or one of its components if it becomes corrupted. This way, users spend less time uninstalling and reinstalling applications.

NOTE

Windows Installer Requirements Windows Installer version 2.0 (the version used to install .NET applications) requires Windows NT 4.0 with Service Pack 6 or later, Windows XP, Windows .NET Server, Windows 2000, or Windows Me. Earlier Windows Installer versions require Windows NT 4.0 with Service Pack 3 or later, Windows XP, Windows 2000, or Windows Me. Windows Installer is also available as a redistributable file for Windows NT 4.0, Windows 95, and Windows 98, and it can be downloaded from www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm.

The Windows Installer manages all installed components on a system by keeping a database of information about every application that it installs , including files, Registry keys, and components.

When you create an installation program using the Windows Installer, you create a Windows Installer ( .msi ) package. This package includes a number of database tables that describe the application to the Windows Installer. When this package is executed on the target machine, the Windows Installer installs the program by reading the installation information stored in the Windows Installer package.

NOTE

Updating Microsoft Windows Installer Although the Windows Installer is built-in Windows technology, you might need to install a redistributable file in order to get the latest version. Later in this chapter, you will see how to create a Windows Installer bootstrapper to ensure that the Windows Installer is updated (if necessary) on target machines.

There are several ways to create a Windows Installer package. The most basic option is to manually create it by using the Windows Installer Software Development Kit (SDK), but for most practical requirements, you would instead use a visual tool that can help with the process. Visual Studio .NET provides a new category of projects, called the Setup and Deployment projects, to create setup packages by using the Windows Installer. Many developers prefer installation tools from independent vendors, such as InstallShield and Wise Solutions. Specialized tools from these and other vendors provide a much higher level of customization and ease for creating Windows Installer ‚ based setup programs.

Microsoft Visual Studio .NET, through its Setup and Deployment projects, offers four types of deployment project templates:

Setup Project
Web Setup Project
Merge Module Project
Cab Project

Visual Studio .NET also has a Setup Wizard that helps you interactively create these deployment templates. I'll briefly discuss the purpose of these deployment project templates in the following subsections. You'll use these templates later in this chapter.

Setup Project

The Setup Project template is used to create installation packages for deploying various types of applications such as Windows applications, Windows Services, console applications, and so on. The setup project creates an ( .msi ) installer package of the application. The setup project installs files into the specified directories in the file system of a target computer.

Web Setup Project

You use this template to create installation packages for deploying Web-based applications such as an ASP.NET Web application or an XML Web service. Like the setup project template, the Web setup project also creates an ( .msi ) installer package, but this installer package installs files to a virtual directory on the target Web server.

Merge Modules Project

Merge modules allow you to package components that can be shared between multiple applications. A merge module is created as an .msm file. Merge modules are created for the use of the authors of applications that use the shared component.

Unlike the Windows Installer setup package ( .msi file), merge modules are not installed directly; instead, merge modules are merged with the installer package of an application that uses the packaged component.

When an application containing a merge module is installed, the Windows Installer maintains the reference count of the component in the Windows database. When another application that uses the same version of the component is installed, the Windows Installer just increases the reference count of the component instead of installing the component. Later, when an application is uninstalled, the Windows Installer checks the reference count of shared components. A shared component is uninstalled only if the component is not being used by any other installed application.

NOTE

Use Authenticode Signing for Downloaded Code To ensure the credibility of code downloaded from the Internet, you should sign the code using Microsoft Authenticode technology. An Authenticode signature uses a digital certificate issued by a third-party certification authority (such as VeriSign or Thawte) to assert a company's identity.

When users download an Authenticode signed download package, they are presented with a digital certificate that shows the name of the software publisher as asserted by the certification authority. If a user trusts the certification authority and the software publisher, he can feel safe in downloading and installing the software package.

You can use the File Signing tool ( signcode.exe ) to attach an Authenticode signature to the assembly.

Using CAB Files

CAB (short for "cabinet") files store a set of files in a compressed archive. A compressed archive might span over one or more files ‚ each having a .cab extension. CAB files can be created using the Visual Studio .NET Cab Project.

CAB files are often used when you need to reduce the size of your distribution. This might be a case in which you want to distribute the programs over the Internet or small- sized media such as floppy disks.

In an enterprise application, you normally use a CAB file to package managed controls or the legacy ActiveX controls that will be hosted on the Web page. The controls are embedded in the Web page using the <object> tag, and the path to the CAB files that contains the control is specified using the CODEBASE attribute. At runtime, such controls are downloaded to the user's computer and executed on demand.

EXAM TIP

The Strong Name and the Authenticode Signature An assembly signed with a strong name does not automatically assert a company's identity, such as its name. For that purpose, you can use an Authenticode signature ‚ in which case, the company's identity is asserted.

An important thing to know is the order of commands when signing an assembly using both sn.exe and signcode.exe . You must sign your assembly with the Strong Name tool ( sn.exe ) before you sign it with the File Signing tool ( signcode.exe ).

Remember, strong names protect the code in an assembly from tampering, whereas signing provides evidence of the assembly's origin.

Customizing Visual Studio .NET Setup and Deployment Projects

When you create a setup and deployment project, you might also want to provide custom features and perform custom actions while performing installation (for example, create Registry entries, provide a customized user interface for installation, perform custom actions, check for conditions to be satisfied for installation, create menu options and shortcuts, and many more).

Visual Studio .NET provides the following editors to customize various aspects of the installation process:

File System Editor ‚ The File System Editor provides a mapping of the file system on the target machine. Each folder is referred to with a special name that is converted to represent the folder on the target machine during the installation process. For example, at the time of installation, the special folder User's Desktop will be converted to the actual desktop path on the target machine.

You can add files to various special folders such as Application Folder , Common Files Folder , Program Files Folder , User's Desktop , System Folder , User's Startup Folder , and many others ‚ each of which represents a particular folder on the target machine.
Registry Editor ‚ The Registry Editor allows you to specify Registry keys, subkeys, and values that are added to the Registry on the target machine during the installation process. You can also import Registry files into the Registry Editor.
File Types Editor ‚ The File Types Editor enables you to associate file extensions and actions with applications. For example, files with an extension ( .qry , .txt , and so on) and action ( open , print , edit , and so on) can be associated with the application. Later, the application will get triggered when ever the associated actions are performed on the files with the associated extensions.
User Interface Editor ‚ The User Interface Editor allows you to customize the user interface that is provided to the user during the installation process. The user interface is made up of the various dialog boxes that appear during the installation process. The user interface provided to the user is divided into three stages: Start, Progress, and End. You can add different types of dialog boxes for each stage. Each stage allows only certain types of dialog boxes to be added.

The User Interface Editor displays the user interface that is applicable during both end user installation and administrative installation. You can customize the user interface for both installation types. The administrative installation occurs when you run the msiexec command-line tool with the /a option. This installation type is intended to place the setup files on a network drive from which they can be executed by other users.
Custom Actions Editor ‚ The Custom Actions Editor allows you to run compiled DLL, EXE, scripts, assembly files, or assemblies at the end of an installation. These files can be used to perform custom vital actions that were not carried out during installation. If the custom action fails, the entire installation process is rolled back. For example, you might have to install the database that is required by your application during the installation process.

You can perform custom actions in four phases: Install, Commit, Rollback, and Uninstall.
Launch Conditions Editor ‚ The Launch Conditions Editor allows you to set conditions that are to be evaluated when an installation begins on a target machine. If the conditions are not met, installation stops. For example, let's say that you would like to install a Visual Basic .NET application only if the .NET Framework is installed on the target machine. This condition is added, by default, by Visual Studio .NET. You might also need to perform other checks, such as whether a particular file exists on the target machine or to verify a particular Registry key value on the target machine.

The Launch Conditions Editor allows you to perform searches on the target machine for a file, a Registry entry, or Windows Installer components. You can then add conditions to be evaluated for the search performed on the target machine.

Setup and Web Setup projects support all the editors provided by Visual Studio .NET. However, the Merge Module Project does not provide support for the Launch Conditions Editor or the User Interface Editor. That's understandable because merge modules are used to package components and not applications. The Cab Project does not support any of these editors.

You can view an editor by either choosing its icon from Solution Explorer or by right-clicking the project in Solution Explorer and choosing View and the respective editor option from the shortcut menu, as shown in Figure 10.15.

Figure 10.15. You can launch various editors for a setup project via Solution Explorer.

REVIEW BREAK

Although the .NET Framework supports XCOPY deployment, XCOPY is not sufficient for advanced deployment requirements. For advanced requirements, you should instead use a Microsoft Windows Installer ‚ based installation package to deploy applications.
The Microsoft Windows Installer is the built-in installation and configuration service of the Windows operating system. In addition to providing several advanced installation features, it provides features such as the ability to roll back an installation process, uninstall an application, and repair a component or an application.
Visual Studio .NET provides four types of deployment templates: Setup Project (for Windows-based applications), Web Setup Project (for Web-based applications), Merge Module Project (for shared components and assemblies), and Cab Project (for Managed and legacy ActiveX components to be downloaded over the Internet). Visual Studio .NET also provides the Setup Wizard, which helps in creating installation packages for any of these deployment projects.

‚ ‚

Top