Choosing a Deployment Strategy

Exactly which method of deployment you choose will depend to a large extent on the nature of your organization, which deployment technologies are available, and the type of the application you are deploying. However, you should ensure that you complete the planning of your deployment before you start any deployment steps, because a different distribution method may dramatically affect how you would package that application.

One of the main factors that determines how an application will be deployed is the nature of the application, in other words is the application Windows Forms-based, or Web-based?

There are three main methodologies for deploying applications:

• No-touch

• Windows Installer package

• File copy

We will look at each of these in turn:

No-Touch Deployment

No-touch deployment is an increasingly popular feature of the .NET Framework used to package Windows Forms-based applications. In this scenario you store the application files (such as executables and DLLs) on a Web server. To install the application, the users connect to the application location using HTTP. The initial files and assemblies that are needed when the application is first run are downloaded to the .NET Framework assembly cache download folder (<windir>\assembly\download\) and the Temporary Internet Files folder. Each additional resource used by your application is automatically downloaded to the client computer, and stored in one of these two locations.

The advantage of this approach is that you can combine all of the richness of a traditional Windows graphical user interface with the manageability and maintainability of Web applications. As resources are downloaded on an "as needed" basis, download time for the initial run of the application is minimized. Then, when other assemblies are needed later, they are downloaded at that time. All of this happens automatically — when your executable file requests a class from another assembly, .NET Framework locates that assembly in the same location on the Web server and downloads it.

Although the application is effectively running from the .NET cache, you can still update your application files on the Web server, and those changes will take place immediately. Before the user's computer loads the assembly, it verifies that the downloaded application files have not changed since it last requested them — if they have, it downloads the later versions as needed.

There are some situations where no-touch deployment is inappropriate. These include:

• Where you need to predict and throttle bandwidth usage. With the application being downloaded on an as-needed basis by users, there is the potential unpredictable spikes in bandwidth usage.

• Where clients need to use the application offline. No-touch deployment applications store the application in the temporary Internet Files folder. Therefore, while it is possible to run the application offline, it will only run those features that have already been downloaded and will not look for updates in offline mode. A good example of this is, you use a word processor with this method, but don't use the spell checker. If you then take this offline, you will still have the word processor cached, but the spell checker function will not be included (because it was never downloaded on demand) and will not work when you ask the word processor to check your spelling. This is true even if you are connected to the network as the browser is running in offline mode.

• Where advanced install operations are needed, such as a driver install or a COM object to be registered.

• Where the application cannot run within the bounds of the default security policy and deploying a different security policy is not practical.

• Where assemblies need to be deployed in the global assembly cache.

If you wish to deploy applications using no-touch deployment, it is a good idea to start planning for the deployment at the application design phase. This allows you to resolve any issues (for example, with security policy) at the design phase rather than attempting to do so as the application is deployed.

Note

You can use a network share rather than a Web server to host your .NET applications. In this case, the users connect to the share and start the executable file from there. This approach is similar to the URL-launched executable file, except that the download cache is not used to cache the downloaded application and assemblies — all assemblies are loaded directly into memory as needed. The absence of caching makes the network share approach less efficient than the Web server approach.

Deploying Shared Assemblies

No-touch deployment does not directly support installing shared assemblies in the global assembly cache. This means that if you wish to install assemblies in the global assembly cache you will need to do so using another mechanism. However, before adopting this strategy you should consider carefully if you need to deploy your assemblies in the global assembly cache at all. A good alternative to using the global assembly cache is to install the assemblies separately with each application. In some cases this can produce manageability problems, but in the case of no-touch deployment these management issues are compensated by the fact that if an assembly is modified, it only has to be updated on the Web server, and will then be downloaded on each client machine the next time the application is run.

Multi-Assembly Applications

Applications consisting of single assemblies are the easiest to deploy using no-touch deployment. However, it is also possible to deploy applications consisting of multiple assemblies, although this can require some work by the application developer. The Assembly class as specified in the .NET Framework Class Library has a LoadFrom method to initialize a reference to a particular assembly. The parameter for LoadFrom is either a URL or a file pathname. When a URL is specified, the .NET Framework first checks to see if the named assembly exists on the client by checking the assembly download cache. If the assembly is not in the assembly download cache, it is fetched from the Web server and a copy is placed in the download cache. Then the assembly object is ready for use in the code.

The advantage of this method is that the assembly is only downloaded if it is invoked by the user, although of course this can lead to a delay when that functionality it required by the user.

For more information about no-touch deployment of .NET-based applications, see the MSDN articles, "Death of the Browser?" and "Security for Downloaded Code." For details, see the More Information section at the end of this chapter.

Windows Installer Package Deployment

In cases where a no-touch deployment will not be appropriate, you would normally look to deploy your applications using Windows Installer packages. Windows Installer packages can be used to deploy all kinds of .NET-based applications, along with merge modules and CAB Files. The Windows Installer packages can be distributed in a number of ways, including placing the installer packages on a file or Web server, using the Group Policy functionality of Active Directory, or using the software distribution capabilities of SMS. Advantages of deploying an application using Windows Installer include:

• A simple-to-use GUI installation program that can be customized

• Integration with Control Panel's Add/Remove Programs utility for:

  • Installing

  • Uninstalling

  • Adding or removing application features

  • Repairing a broken installation

• A setup routine that:

  • Can run in silent mode, with no user interaction

  • Rolls back the system to the state it was in prior to the start of installation if any part of the setup routine fails

  • Rolls back the system to the state it was in prior to the start of installation if the user cancels the installation part way through the setup routine

Using Windows Installer packages, you can control almost every aspect of application installation. A Windows Installer package can:

• Run prerequisite hardware and software checks prior to installation

• Create desktop and Start menu shortcuts for running the application

• Manage file and folder locations

• Manipulate the Registry

• Create File Associations

• Install COM and COM+ Objects

• Install assemblies into the Global Assembly Cache

• Run custom tasks after installation is complete

• Maintain version information, ensuring that patches and upgrades are installed in the correct order

Using Windows Installer packages can resolve many of the issues surrounding deployment of more complex Windows-based and Web-based applications. The following table describes some of these issues and explains the advantages of using Windows Installer files for deploying solutions that include these features.

Table 2.2: Installation Issues for More Complex Windows and Web Applications

Feature	Installation Issues
Shared Assemblies	Windows Installer files provide an easy and reliable mechanism for installing assemblies into the global assembly cache.
Legacy COM Components	If your Web application includes legacy COM components, they need to be installed and registered properly before they can be used. Windows Installer files provide an easy and reliable mechanism for installing and registering COM components. However, you can also use RegSvr32 to manually register your COM libraries.
IIS Settings	Simply copying build outputs for your Web applications does not copy IIS settings from your development computer to the production Web server. You need to manually change any settings that need modifying or develop a script for ensuring the correct settings are in place. An easier approach is to use a Web setup project to package your solution in Windows Installer files — you can specify IIS settings for your Web setup project to have them applied when you run the installer package.
Application Resources	Windows Installer files provide an easy way to deploy application resources, such as message queues, event logs, and performance counters, along with your project outputs. You can use predefined installation components provided by Visual Studio .NET in your project to deploy this type of application resource. After you add the required predefined installation components to your application's project, you can easily add them to the Windows Installer project as custom actions. Similarly, if you have created installer classes to handle the deployment of other application resources for which there are no predefined installation components (such as serviced components), you can also add them to your setup project as custom actions.

Using Windows Installer Packages for Multi-Tiered Applications

For a multi-tiered application, you should build separate installers for each different physical tier. Building separate installers is appropriate for most scenarios because it is extremely complex (and in some cases impossible) to run an installer on one specific physical tier and have other physical tiers deployed to other computers as part of the same installation process. For example, if you are running the installer on your Web server, it is difficult to deploy your business logic components to a separate computer. In some cases different physical tiers may even be suited to different packaging strategies. For example, the Web tier might best be deployed as a collection of build outputs, while the business logic tier and database server might best be packaged in one Windows Installer file, with perhaps a Windows Forms-based application packaged in another installer.

Security Considerations

One issue that affects deployment of Windows Forms-based applications to users with Windows Installer files is whether the user running the setup will have the required privileges to complete the installation. The privileges required depend on the actions that the Windows Installer file performs and the platform that users are installing your application onto. For example, no special privileges are required to install applications on Windows 95, Windows 98, or Windows Me, whereas even creating an application folder beneath the Program Files system folder on Windows 2000 or Windows XP by default requires that the user to be a member of a local group with elevated privileges, such as Power Users or Administrators.

When a user who is not a member of the local Administrators group attempts to run a Windows Installer file on Windows 2000, the user is first prompted that he or she may not hold sufficient permissions to complete the installation. They are also offered the choice of running the installer file as a different user who does have all required permissions (Administrator by default). To be able to run the installer file as a different user, the person running the installation needs to know the password for that account.

One way to ensure that your Windows Installer file will not fail due to insufficient privileges is to distribute it with an electronic software deployment tool, such as SMS or Active Directory Group Policy for software distribution. Both of these tools allow you to run your Windows Installer file with administrator privileges, regardless of the privileges held by the user logged on to the computer.

Distributing Windows Installer Packages

There are a number of ways that Windows Installer packages can be distributed to users or computers. These are:

• Group Policy functionality of Active Directory

• Systems Management Server (SMS)

• Other Methods (including placing files on a Network Server, Web Server, or Distributing media)

We will look at each of these in turn:

Group Policy Functionality of Active Directory

Active Directory allows you to distribute applications to users or computers automatically using Group Policy. Group Policy Objects can be defined at a domain level, site level, OU level, or local computer level. Using Group Policy you can ensure that applications are installed automatically when a specific user starts their computer or logs on, or you can ensure that the applications appear automatically in Add/ Remove Programs.

Group Policy allows you to distribute applications in two ways — assigning and publishing. The table compares the two methods.

Table 2.3: Assigning and Publishing Applications with Group Policy

Distribution Strategy	Description
Assigning Software	You can assign a program distribution to users or computers. If you assign the program to a user, it is installed when the user logs on to the computer. When the user first runs the program, the installation is finalized. If you assign the program to a computer, it is installed when the computer starts, and is available to all users that log on to the computer. When a user first runs the program, the installation is finalized.
Publishing Software	You can publish a program distribution to users. When the user logs on to the computer, the published program is displayed in the Add/Remove Programs dialog box, and it can be installed from there. Alternatively you can specify that the program is installed when a user attempts to open a file type associated with the application.

To allow you to install application using Group Policy, your destination computers must be running Windows 2000 or greater and be part of an Active Directory environment.

You do not have to use Windows Installer packages in order to use Group Policy as a distribution mechanism, however it does provide you with the most flexibility when choosing your distribution options. The Windows Installer packages can be assigned to users or computers, or published.

• To assign a Windows Installer (MSI) package to computers using Group Policy

  1. Create a folder to hold the MSI package on a network server. Share the folder with appropriate permissions to allow the users and computers to read and run these files, and then copy the MSI package file into this location.

  2. Start the Active Directory Users and Computers snap-in.

  3. From Active Directory Users and Computers, click the object that contains the computers you wish to assign the application to. Right-click that container, click Properties, and then click the Group Policy tab.

  4. If necessary, create a new GPO for installing your MSI package, and give the new GPO a descriptive name (you could also use an existing GPO).

  5. While the GPO is selected, click Edit. This starts the Group Policy snap-in and lets you edit this GPO.

  6. Expand Computer Configuration, Expanding the Software Settings folder and selecting the Software Installation icon, Right-click Software Installation, choose New, and Package…

  7. You are prompted for the path to the Windows Installer file (.msi) for this package. View the network location that contains the Windows Installer file, click the file, and then click Open.

     Warning

     If the Windows Installer file resides on the local hard disk, do not use a local path, instead, use a UNC path (such as \\servername\sharename\path\filename.msi) back to the local computer to indicate the location of the installation files. Otherwise, client computers that try to install the package will look on their local hard disks in the location that was indicated, and will not find the installation files at that location, so the installation does not work.

  8. When prompted to choose between Assigned, Published, and Advanced Published or Assigned, click Assigned. Click OK.

     Note

     Choosing Advanced will bring up another window that will allow you to make modifications to the delivery of the package. This can include upgrades, applying transforms and security settings. Of course these advanced settings can also be modified after you choose OK by selecting the package, right-click and choose Properties.

  9. Close the Group Policy snap-In.

  10. Close Active Directory Users and Computers.

Note

For more information on how to create Windows Installer packages, see Chapter 3, "Implementing the Deployment of .NET Framework-based applications.

Systems Management Server (SMS)

Systems Management Server 2.0 provides some significant functionality aimed at making software distribution easier and more accountable. If you already have SMS in your environment, you should strongly consider using it for distributing your .NET-based applications. If you do not currently have SMS deployed, you should consider the benefits it will bring to your organization. These include:

• Software distribution to multiple client platforms. All Windows-based platforms are supported by SMS.

• WAN-aware automated distribution of software. SMS can monitor its band-width usage and throttle it if it is using more than it should at a particular time of day. This allows you to ensure that software is not installed over the WAN at inappropriate times.

• Targeting to specific users and computers. Software can be distributed based on user names, group names, computer names, domain names, network addresses, or inventory collection values.

• Scheduled application deployment. Software can be distributed at a specific time. This may be useful to reduce the load on the network at certain times of day.

• Status of application deployments. This allows you to gain an enterprise view of the application deployment.

• Reporting of successes/failures. Just because an application should have been deployed to a particular client does not necessarily mean that the deployment was successful. SMS will report if a deployment succeeded or failed, allowing you to take action if there were problems in distributing the software to particular clients.

SMS also has a number of other features that are closely related to the successful distribution of applications. These include:

• Inventory management. Provides you with a record of the existing hardware and software deployed throughout your enterprise. Inventory information is a critical part of effective change and configuration management, allowing you to properly plan and deploy applications.

• Application usage tracking (metering). Allows administrators to make smart purchasing and deployment decisions because they understand what applications their customers are using.

• Status and reporting. Allows administrators to monitor activity to ensure that the correct software to the correct locations when needed.

SMS does not require that you use Windows Installer packages, as it has its own packaging mechanism. However, you can still use SMS to deploy Windows Installer packages to clients.

For more instructions on using SMS to deploy applications, see the product documentation (http://www.microsoft.com/smserver/techinfo/productdoc/default.asp).

Other Methods

There are a number of other methods that are used to distribute Windows Installer packages. The following table outlines their uses:

Table 2.4: Methods of Distributing Windows Installer Packages

Method	Description	Strengths/Weaknesses
Web/FTP Server	Installer package is placed on a Web server and the link sent out to users so they can download it.	Good way of making packages available over the Internet and intranet. Package can be zipped to prevent over the network install. No control over when downloads occur. Local Admin rights required to install package.
Network Server	Installer package is placed on a network server and the link sent out to users so they can download it.	Good way of making packages available internally. Package can be zipped to prevent over the network install. No control over when downloads occur. Local Admin rights required to install package.
E-mail	Installer package sent through e-mail system.	Easy to find package. E-mail system may block installer package. Can place considerable load on e-mail system. Local Admin rights required to install package.
CD/DVD	Installer package burned to CD/DVD	Portable media. Suitable where bandwidth is low. Local Admin rights required to install package.

Choosing Between Group Policy and SMS for Distribution

Although there are a large number of methods for distributing Windows Installer packages, often the decision comes down to a straight choice between Group Policy and SMS. You may have Active Directory deployed within your environment, but are considering using SMS in the future for application distribution. The following table will help you decide if SMS is required to meet your Application distribution needs.

Table 2.5: Choosing Between Group Policy and SMS for Distribution

Issue	Active Directory Group Policies	SMS
Reporting	Windows Installer events and messages are stored on the local computer, rather than in a central location. If an administrator requires reporting on which users or computers were updated, they need to connect to each computer and view the event logs.	SMS provides for centralized reporting and management.
Distribution	Active Directory requires an administrator to manually create and manage software distribution points. If multiple installation points are required, administrators need to synchronize them. Windows 2000 Distributed File System (DFS) can be used to streamline this process. Each distribution point requires a separate Group Policy.	SMS uses a distribution point hierarchy which is automatically synchronized and managed. SMS also compresses the packages prior to delivery to remote install points.
Targeting	Targeting with Group Policy is based on organizational unit membership and policy application.	SMS targets collections based on inventory values. Collections are dynamic and query-based.

Automating the Creation of Installers

If you are an independent software vendor (ISV), or if you need to deploy a large number of .NET-based applications for your enterprise, you might want to automate the creation of your setup routines. For example, you might want to build your own application for creating setup programs to standardize deployment practices, or you might want to write scripts that create installers for multiple applications. If the other factors described in this chapter bring you to the conclusion that an .msi (or .msm) file is appropriate for your applications, you can automate the creation of your setups by using the automation interface provided by the Windows Installer, rather than creating your installers using Visual Studio .NET.

For in-depth information about the Windows Installer automation interface, see the "Automation Interface" section of the Platform SDK on MSDN.

Tools for Creating Windows Installer Packages

In addition to the deployment tools included in Visual Studio, installation tools that support Windows Installer are available from third-party vendors. These tools may support additional Windows Installer authoring features that are not available in Visual Studio deployment projects.

Third party tools for creating Windows Installer Packages include:

• InstallShield Developer. A Windows Installer setup-authoring solution that provides complete control of the Windows Installer service and full support for .NET-based application installations. The Developer edition provides the option to create .NET installations directly from within the Microsoft Visual Studio .NET integrated development environment (IDE) or from the traditional InstallShield Developer IDE.

  InstallShield Developer features Visual Studio .NET project wizards, dynamic links with Microsoft Visual C# .NET development tool and Visual Basic .NET development system projects, .NET COM interop support, .NET assembly installation configuration, and .NET Framework distribution in addition to a Windows Installer direct table editor. For more information on this product, see the InstallShield Web site (http://www.installshield.com/isd/).

• Wise for Visual Studio .NET. A tool that operates directly within Microsoft Visual Studio .NET. It merges the installation and application development lifecycles so that applications and installations are designed, coded, and tested together. For more information, see the Wise Web site (http://www.wise.com/visualstudio.asp).

Deploying a Simple Collection of Build Outputs

For many Web applications, and some more simple Windows-based applications, it is appropriate to use a file copy mechanism to deploy the application to a server. In this case you deploy your application as a simple collection of build outputs, rather than by applying any further packaging. The term build outputs refers to the application files that comprise your application, such as ASPX files, executables, DLLs, configuration files, graphics, and other resources.

The advantages of packaging your application files as a collection of build outputs include:

• Ease of deployment. The build outputs and other files can simply be copied to the target computer.

• Ease of update. Updated files can simply be copied once again to the target computer.

Unlike Windows Forms-based applications, Web applications are usually installed by an administrator or other skilled IT professionals. In many cases, they are not installed, uninstalled, or repaired using Add/Remove Programs in Control Panel. Additionally, rolling back the installation is not usually required if a problem occurs within the setup routine — it is often easier for the administrator to fix minor problems, such as modifying IIS settings or managing the failed copy of a certain file, than it is to roll back the entire process and start again.

However, while this type of deployment can work well for more simple applications, you would preferably use one of the other techniques if you need to do any of the following:

• Make changes to the Registry

• Add, remove, or change Windows Services

• Make security policy changes

• Change service or user accounts

• Change COM components or updates to strong named assemblies (Private or global assembly cache)

• Ensure that all dependencies are noted and registered

For more complex applications, such as those that include shared assemblies or those that rely on specific IIS settings to be in place, using Windows Installer technology may still be a better choice.

Distributing a Simple Collection of Build Objects

Distribution mechanism for a simple collection of build objects can include any of the following:

• Microsoft Application Center 2000 (for Web farm deployment)

• Copy Project functionality of Microsoft Visual Studio .NET 2003 (only suitable for Web-based applications)

• File Copy Distribution

We will discuss each of these in turn:

Microsoft Application Center 2000

If you are deploying Web-based or server-based applications, in many cases the content and components will exist on a Web cluster of up to 12 servers. When deploying your application you need to ensure that the software is distributed to all of the servers in the cluster and synchronized across each element of the cluster. You can use Application Center to distribute and synchronize any of the following throughout your Web cluster:

• Web sites, virtual directories (and their associated ISAPI filters), and ASP.NET applications (including XML Web Services)

• Configuration files (such as web.config, application configuration files, and machine.config)

• Private assemblies

• Discovery files

• Symbols

• HTTP modules and HTTP handlers

• Localized content

• Secure Sockets Layer (SSL) Certificates

• Server Configuration information (such as IIS metabase settings, CLB configuration, and NLB configuration)

Note

Many of these elements require administrative privileges to be installed. Application Center will manage this, pushing the components out to the appropriate machines with no requirement to log on locally to each machine.

Application Center is designed for managing and deploying content and components to a server environment. It is best suited for deploying build outputs and content files for Web applications and COM+ applications.

You can also use the deployment and synchronization features of Microsoft Application Center to manage SSL certificates. Application Center detects that your application relies on a certificate and automatically configures each member of your cluster accordingly.

Note

Certificates should be backed up onto portable media and stored in a well-known place for emergencies or for configuring new servers.

By contrast Application Center is not suitable for deploying applications packaged in Windows Installer files or other executable setup programs (for example desktop applications, Windows service applications, or other client-based applications). Nor is it designed to deploy SQL Server databases and manage their schemas, or message queues. If you are deploying these types of technologies, you must consider using other distribution mechanisms.

By default, Application Center cannot install assemblies into the .NET global assembly cache for members of your Web farm or application farm clusters. However, a patch to resolve this issue has been published. For more details see the Microsoft Knowledge Base Article 326950, "INFO: Application Center 2000 GAC Replication Support for Windows 2000". This functionality will also be included in Application Center 2000 Service Pack 2.

If you are going to use Application Center 2000, you must install the product on all the servers in your Web farm or application server farm. Once Application Center is deployed, it will automatically configure your server applications (and their constituent parts) when you distribute content to cluster members. This prevents you from having to specify detailed actions for your deployment. For example, if you replace an existing COM component using Application Center, it will stop the IIS Service, remove the registration of the old component, replace the component files, register the new component and restart the IIS Web Service. Without Application Center you would need to perform each of these tasks manually, or script them.

One of the major advantages of using Application Center to deploy Web applications and server applications in your clustered server environment is that you can use it to manage the different stages of your application lifecycle. You can move your applications from your development environment to your test servers, from your test servers to your staging environment, and finally from your staging server(s) to your production cluster with the same mechanism. Using Application Center to move your solutions between these different environments provides you with consistency advantages. For example, having successfully moved your application from development to the test environment, and then from the test servers to your staging servers, you can have confidence that, as you deploy your application to the final production environment, no unexpected changes or problems are introduced that arise from the actual process of distributing the application to the production environment. This makes it easier to track down any issues that arise in the live environment.

Visual Studio 2003

If you are distributing a Web application, you can use the Copy Project command in Visual Studio .NET 2003 to create the new Web application on a target server. You can choose to include:

• Only the files required to run to the application, including build outputs, DLLs and references from the bin folder, and any files with the BuildAction property set to Content.

• All project files, including build outputs, DLLs, and references from the bin folder, and all other files.

• All files in the project folder and subfolders.

The latter two options include the project file and source files. For this reason, when deploying to a production environment, you should generally choose the first option. However, this does mean that although a new virtual directory is created on the target server, IIS settings will not be copied from the original environment to your target server. Instead the new virtual directory inherits the default settings from the Web site. You will need to apply the appropriate settings separately, either by developing and running IIS scripts or by manually applying the setting your Web application requires.

When using Copy Project, the target server must be prepared to receive the files in the project. You should create a file share on the server, or install Front Page Extensions so that the Web site can be created directly by Visual Studio .NET 2003.

Note

For more information about using the Copy Project command, see "Deployment Alternatives" on MSDN.

File Copy

A simple file copy can be used to deploy some .NET-based applications. However, this type of distribution is only viable when there is no need to modify the registry or perform other tasks, such as stopping IIS when changes have occurred.

XML Web services and ASP.NET Web applications lend themselves very well to copy-type deployment. Previously, these types of applications were built using IIS and traditional COM components. Installing the components for these applications usually involved registering the component during the deployment process by using the Regsvr32.exe utility. Updating existing components was far more troublesome, and required stopping the IIS service, using the Regsvr32.exe utility to remove the registration of the old component, copying and registering the new component (again using Regsvr32.exe), and finally starting the IIS service again. These steps are no longer needed for XML Web services and ASP.NET Web applications. IIS does not place exclusive file locks on .NET assemblies and can detect changes to your solution files, automatically using the new versions on the fly. Also, because assemblies are self-describing, they don't have to be registered.

Using a simple copy mechanism to deploy your applications suffers from some drawbacks. These include:

• You require an additional step to install shared assemblies into the global assembly cache. You can install an assembly into the global assembly cache by using the Gacutil.exe utility with the /ir switch, which installs assemblies into the global assembly cache with a traced reference. These references can be removed when the assembly is uninstalled by using the /ur switch.

• You cannot automatically configure IIS directory settings for your Web application. You will have to define these manually or run a script to perform this configuration.

• You cannot automatically manage the rollback or uninstall of your application.

• You cannot include launch conditions, such as those available in Windows Installer files.

• You cannot automatically manage conditional deployment scenarios.

• You cannot automatically manipulate registry settings and file associations — you will manually have to edit the registry on your target computer or import .reg files to ensure appropriate settings are in place.

• You cannot take advantage of Windows Installer features, such as automatic repair (although this is usually not a major issue for Web applications).

Note

You can also use drag-and-drop in Windows Explorer to move shared assemblies into the Global Assembly Cache folder. However you should avoid this method as it does not implement any reference counting. Without reference counting, the uninstall routine of another application can result in the premature removal of a shared assembly from the global assembly cache, which would break your application that relies on that assembly.

Note

For more information on using File Copy to deploy .NET-based applications, see the MSDN article, "Determining When to Use Windows Installer Versus XCOPY." For further details see the More Information section at the end of this chapter.

If you are deploying more complex applications as a collection of build objects, you will generally have to supplement the file copy operations with scripts and utilities to complete the installation. For more details on this see Chapter 3, "Implementing the Deployment of .NET Framework-based Applications."

Host Header Issues for Web Applications

Although for many scenarios you can consider packaging your Web applications in a Web setup Windows Installer file, there is one situation in which deploying a collection of build outputs is much more appropriate. This scenario is where you need to deploy your Web application to a Web server that distinguishes between sites based on host headers.

Host header names can be used to host multiple domain names from one IP address. To distinguish one Web site from another on the same computer, IIS uses the following three elements:

• TCP/IP address

• TCP port

• Host header name

As long as at least one of these three items is unique for each Web site, IIS can manage multiple sites. When IIS receives a request for a Web page, it looks at the information sent in by the browser. If the browser is HTTP 1.1 compliant (for example, Internet Explorer 3.x and later, or Netscape Navigator 3.x and later), the HTTP header contains the actual domain name requested. IIS uses this to determine which site should answer the request. Although Web setup projects allow you to specify which port to install the application on, they do not currently support deployment of a Web application to a site differentiated by host headers. Therefore, you need to consider alternatives to using Web setup projects to package your Web applications if you need to deploy in this scenario.

One approach that you might consider is to copy the build outputs of your Web application to the appropriate location on the target Web server, and then build a separate standard Windows Installer file for deploying the components that have more complex setup requirements. The person running the installer needs to ensure that the components are installed into the correct folders.