Application Deployment

In the context of this chapter, application deployment includes two principal functions:

• The process of taking an application, packaging it up, and installing it on another machine

• The process of updating an application that has already been installed with new or changed functionality

Deployment can, in some cases, also include placing the .NET Framework itself on a particular machine. This chapter assumes that the .NET Framework is installed on any machines in question. During the discussion of creating deployment projects, you will learn what to do if the .NET Framework is not available on a system.

Why Deployment Is Easier in .NET

Pre-.NET applications for Microsoft Windows were typically based on a technology called COM. While COM had many interesting benefits as a development platform, its most significant weakness was deployment. All components in a COM environment had to be registered, which means that they had a record embedded in the local machine’s registry to assist in identifying and locating the component.

COM components also had inflexible versioning capabilities, resulting in the possibility that two versions, both needed by applications, could not simultaneously be available on the same machine. The versioning requirements of COM led to a condition colloquially referred to as DLL hell.

As covered in the previous chapter, assemblies in .NET are self-describing. All the information needed to execute an assembly is normally contained in the assembly itself. There is no need to place any information in the Windows registry. If the CLR can find an assembly needed by an application (the process of location is discussed in Chapter 21), then the assembly can be run.

The previous chapter also discussed side-by-side execution of .NET assemblies. Multiple versions of an assembly can be executed by .NET, even if they have exactly the same interface and nominal version number. The implication for deployment is that each application can deploy the assemblies it needs and be assured that there will be no conflict with the assemblies needed by other applications.

These .NET capabilities provide a range of deployment possibilities, from simple to complex. Let’s start by looking at the simplest method of deployment, which harkens back to the days of DOS-XCOPY deployment.

XCOPY Deployment

The term XCOPY deployment was coined to describe an ideal deployment scenario. Its name derives from the DOS xcopy command. With XCOPY deployment, all you have to do to deploy an application is copy the directory (including all child directories) to the computer on which you would like to run the program.

XCOPY deployment was not available for older COM-based software because a COM component had to be registered on the machine. Because no registration is needed in .NET, and because the .NET CLR always looks in an application’s directory for necessary assemblies, copying assemblies into the application directory is quite sufficient.

XCOPY deployment is fine for very simple applications, but most business applications require other dependencies (such as databases and message queues) to be created on the new computer. .NET cannot help with those, so applications that have them need more sophisticated deployment.

Using the Windows Installer

The Windows Installer service is available on all operating systems that support .NET Framework 3.0. It was specifically created for installation of applications onto a Windows system.

The Windows Installer service uses a file called a Windows Installer package file to install an application. Such files have an extension of .msi, which is an acronym derived from “Microsoft Installer.” The files that make up a product can be packaged inside the .msi file, or externally in a number of cabinet files.

When users request that a particular application be installed, they can just double-click the .msi file. The Windows Installer service reads the file and determines what needs to be done (such as which files need to be copied and where they need to be copied to) to install the application. All the installation rules are implemented centrally by the service and do not need to be distributed as part of a setup executable. The Windows Installer package file contains a list of actions (such as copy file mfc40.dll to the Windows system folder) and what rules need to be applied to these actions.

The Windows Installer service also has a rollback method to handle failed installations. If the installation fails for some reason, the Windows Installer service will rollback the computer to its original state. You can manually create a Windows Installer package file using the Windows Installer SDK tools. However, it’s much easier to use Visual Studio. Several templates in VS 2005 create projects that output .msi files, as discussed in detail in the section “Visual Studio Deployment Projects.”

ClickOnce Deployment

An alternative to Windows Installer for Windows Forms applications is ClickOnce. This deployment technology was first included in Visual Studio 2005. Creating ClickOnce deployments is simpler than creating .msi files, but the most important ClickOnce advantage is that it is designed to deploy over the Internet. ClickOnce is discussed in the section “Internet Deployment of Windows Applications.”