July 28, 2011, 6:09 a.m.
posted by fractal
Packaging a .NET Application for Deployment
Deploying Multi-tier 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 may also sometimes be 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 multi-tier application. The most common approach is to use a separate deployment mechanism for each tier of the application.
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 correct packaging technique is important because it not only eases the process of deployment but also minimizes the total cost of ownership for the 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.
Packaging an Application for Deployment by Copying the Files
Applications developed using the 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 to delete the folder that contains the application's files. Because the deployment process is non-intrusive and causes minimal changes on the target computer, it is also sometimes called zero-impact installation.
However, there are scenarios where copying the files is not sufficient for deploying an application. Some common installation tasks that are difficult to do just by copying the files include the following:
Because of these limitations, in general you use the XCOPY command only when the application is deployed by the system administrators or the application developers. This may be true for server-side applications because they are deployed on only a few servers and these servers are more likely to be closely administered.
On the other hand, if you are distributing your application commercially, in most cases you would like to package your application as a Windows Installer package.
Using Microsoft Windows Installer to Package an Application for Deployment
Microsoft Windows Installer is an installation and configuration service that is built into the Windows operating system. It gives you complete control over the installation of an application, a component, or an update.
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, Windows Installer also offers several advanced features, some of which are listed here:
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.
Updating Microsoft Windows Installer Although Windows Installer is built into Windows, you might need to install a redistributable file to get the latest version. Later in this chapter you will see how to create a Windows Installer bootstrapper to ensure that Windows Installer is updated (if necessary) on target machines.
When you create an installation program for 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, Windows Installer installs the program by reading the installation information stored in the Windows Installer package.
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 that create setup packages by using 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.
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.
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 a target computer's file system.
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 Module Project
Merge module projects enable you to package components that may 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 component's reference count in the Windows database. When another application that uses the same version of the component is installed, instead of installing the component, Windows installer just increases the component's reference count. Later, when an application is uninstalled, 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.
CAB (short for "cabinet") files store a set of files in a compressed archive. A compressed archive may span over one or more files, each having a .cab extension. You can create CAB files by using the Visual Studio .NET Cab Project.
CAB files are often used when you need to reduce the size of your distribution. This may be necessary when you want to distribute the programs over the Internet or on small-sized media such as floppy disks.
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. A user who trusts the certification authority and the software publisher can feel safe downloading and installing the software package.
In an enterprise application, you normally use CAB files 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 with the <object> element, and the path to the CAB files that contains the control is specified by the CODEBASE attribute. At runtime, such controls are downloaded to the user's computer and executed on demand.
Customizing Visual Studio .NET Setup and Deployment Projects
When you are creating 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 so on).
Visual Studio .NET provides the following editors to customize various aspects of the installation process:
The Setup and Web Setup project templates support all the editors provided by Visual Studio .NET. However, the Merge Module Project template does not provide support for the Launch Conditions Editor and User Interface Editor. This is understandable, as they are used to package components and not applications. The Cab Project template does not support any of these editors.
You can view an editor by either choosing its icon from Solution Explorer or right-clicking the project in Solution Explorer and choosing View and the respective editor option from the shortcut menu, as shown in Figure.