Packaging a .NET Application for Deployment

Packaging a .NET Application for Deployment

Plan the deployment of and deploy a Windows service, a serviced component, a .NET Remoting object, and an XML Web service.


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:

  • 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 may need to take extra steps to provide for the application's integration with the user's desktop, such as creating shortcuts and Start menu entries.

  • You may need to add shared assemblies to the GAC.

  • You may need to allow users to select features during installation.

  • You may need to copy files to relative paths on the target machine that differ from the paths on the source machine.

  • You may need to create or configure databases during the installation.

  • You may need to add custom event logs and performance counters to the target machine.

  • You may need to check whether the .NET Framework is installed on the target machine.

  • You may need to present a user-friendly and branded user interface to the users.

  • You may need to do license key management and user registration as part of the installation.

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:

  • It enables you 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.


    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

  • It provides on-demand installation of features. This capability enables 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 add just a single feature.

  • It enables you to roll back an installation. Windows Installer maintains an undo operation for every operation that is performed during an application installation. If Windows Installer encounters any errors while installing an application, it can uninstall everything that was installed during the installation.

  • It enables you to uninstall an application without breaking any other application that depends on it.

  • It enables you to fix an application or one of its components if it becomes corrupted. This way, users spend less time uninstalling and reinstalling applications.

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.

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

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.

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

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:

  • 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 the 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 actions (open, print, edit and so on) can be associated with the application. Later the application will get triggered whenever the associated actions are performed on the files with associated extensions.


    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 both the sn.exe and signcode.exe tools are used to sign an assembly. You must sign your assembly with the Strong Name tool (sn.exe) before you sign it with the File Signing tool (signcode.exe).

  • User Interface Editor— The User Interface Editor enables you to customize the user interface that is provided to the user during the installation process. The user interface is 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 of these types of installations. The administrative installation occurs when you run the msiexec command-line tool with the /a option.

  • Custom Actions Editor— The Custom Actions Editor enables you to run compiled DLLs, EXEs, scripts, or assembly files at the end of an installation. These files can be used to perform custom actions that are vital but were not carried out during the installation. If the custom action fails, the entire installation process is rolled back. For example, you might have to install the database that your application requires during the installation process.

    You can perform custom actions in four phases: Install, Commit, Rollback, and Uninstall.

  • Launch Conditions Editor— The Launch Conditions Editor enables you to set conditions that are to be evaluated when an installation begins on a target machine. If the conditions are not met, the installation stops. For example, let's say you would like to install a Visual C# .NET application only if the .NET Framework is installed on the target machine. This condition is by default added by Visual Studio .NET. You might also need to perform other checks, such as whether a particular file exists on the target machine, or verify a particular Registry key value on the target machine.

    The Launch Conditions Editor enables 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.

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.

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



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

  • 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 capability 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.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows