Chapter 7 — Deploying and Updating Smart Client Applications

 

Smart Client Architecture and Design Guide

David Hill, Brenton Webster, Edward A. Jezierski, Srinath Vasireddy and Mohammad Al-Sabt, Microsoft Corporation; Blaine Wastell, Ascentium Corporation; Jonathan Rasmusson and Paul Gale, ThoughtWorks; and Paul Slater, Wadeware LLC

June 2004

Related Links

Microsoft® patterns & practices Library (https://msdn.microsoft.com/en-us/practices/default.aspx)

Application Architecture for .NET: Designing Applications and Services (https://msdn.microsoft.com/en-us/library/ms954595.aspx)

Summary: This chapter describes how to best use the deployment features provided by the .NET Framework in your smart clients and the Windows platform and provides guidance on how to choose between the deployment and update mechanisms available.

Contents

Deploying the .NET Framework
Deploying Smart Client Applications
Choosing the Right Deployment Approach
Deploying Smart Client Updates
Choosing the Right Update Approach
Summary

Smart client applications perform local processing on the client computer, and so need to be deployed on those computers. In the past, deploying, updating, maintaining and uninstalling applications over time on client computers was difficult and problematic. With COM, several problems made it very difficult to deploy applications to the client computer, including:

• Applications that were tightly coupled with the registry. Installing a COM application required registering classes and type libraries in the registry.
• Applications that were not self-contained. Besides having to register classes and types in the registry, applications typically included shared files located on disk as well as configuration settings contained in the registry. The application wasn't self-contained; rather, its constituent parts were distributed to different areas on the computer.
• Components that could not be deployed side by side. It was not possible to deploy two different versions of the same DLL into the same directory.

These problems were a large barrier to effective deployment and maintenance of client applications.

The Microsoft® .NET Framework has a number of features that simplify the process of deploying .NET Framework applications. These features include:

• Self-describing assemblies. .NET Framework assemblies contain metadata that describes (among other things) version information, types, resources, and details of all referenced assemblies. This means that they are not dependent on the registry.
• Versioning and side-by-side support. The .NET Framework has extensive support for versioning, allowing you to install multiple versions of an application and multiple versions of the .NET Framework, so that they can run side by side.
• Isolated applications. .NET Framework assemblies can be deployed to the application directory, for use by that specific application, and by default are kept, isolated from other applications. This means that assemblies do not need to be deployed to the Windows directory or explicitly registered in the registry, and reduces the likelihood that they are overwritten or deleted when installing other applications.
• Global assembly cache. If you want to share code among different applications on the same computer, you can deploy components to the global assembly cache. The global assembly cache allows different versions of the same assembly to coexist. When referencing assemblies in the global assembly cache, you must specify the fully qualified name of the assembly that includes the public key token and version number. This helps prevent unintentional use of a different version of a component.
• Default run-time binding against build-time assemblies for strong-named assemblies. By default, if an assembly is strong named, the .NET Framework binds to the exact version of its dependent assemblies. This reduces application fragility because the .NET Framework loads the exact versions of the assemblies that it was built and tested against. This behavior can be explicitly overridden if required.

Collectively, these changes help to address many of the underlying issues that plagued the deployment and maintenance of rich client applications in the past. For more information about how the .NET Framework simplifies deployment, see "Simplifying Deployment and Solving DLL Hell with the .NET Framework" at https://msdn.microsoft.com/en-us/library/ms973843.aspx.

This chapter describes the options for deploying the .NET Framework itself, and then examines how to deploy smart client applications based on the .NET Framework. There are a number of options for deploying your applications, and each is discussed, followed by a discussion in selecting the method most appropriate for your environment. Finally the options for deploying application updates are examined in some detail.

Deploying the .NET Framework

.NET smart client applications rely on the .NET Framework to function, and therefore require it to be deployed on the client computer. The .NET Framework is deployed using the.NET Framework redistributable package, which can be obtained from Microsoft MSDN® or the Windows Update Web site.

You can also obtain the redistributable package from a product CD or DVD. The package is available on the .NET Framework SDK, and on the Microsoft Visual Studio® .NET 2003 DVD.

The .NET Framework redistributable package is actually a Windows Installer package that is wrapped into a single, self-extracting executable file named Dotnetfx.exe. The Dotnetfx.exe executable file starts Install.exe, which performs platform checks, installs Windows Installer version 2.0 if necessary, and then starts the Windows Installer package (.msi file).

For more information about using Dotnetfx.exe, see ".NET Framework Redistributable Package 1.1 Technical Reference" at https://msdn.microsoft.com/en-us/library/ms994356.aspx.

Preinstalling the .NET Framework

Today, many enterprises choose to deploy the .NET Framework as part of their standard operating environment. You can deploy the .NET Framework across your enterprise in two ways:

• Use technologies for pushing software to client computers, such as the Group Policy functionality of Microsoft Active Directory® directory service, or Microsoft Systems Management Server (SMS). Using Group Policy software deployment to install the package over the network allows you to ensure that the package is installed with elevated privileges. Similarly, using an enterprise push technology such as SMS allows you to install the .NET Framework with the required permissions. To install the .NET Framework using Group Policy or SMS, you first need to extract the Windows Installer file from dotnetfx.exe. For more details about how to do this, see "Redistributing the .NET Framework" at https://msdn.microsoft.com/en-us/library/ms994395.aspx.
• Require that end users deploy the .NET Framework themselves by using Windows Update, or by downloading the .NET Framework from a network share, an internal Web site, or the Microsoft Web site. End users will need to have administrative privileges on their computers to deploy the .NET Framework because the .NET Framework Redistributable Package setup program requires administrative privileges to install.

Installing the .NET Framework with an Application

In cases where you cannot determine which computers have the .NET Framework preinstalled, you may choose to install the .NET Framework only when it is required — in other words, when a .NET Framework application is installed. This approach is particularly useful when you do not know the exact software configurations of the computers you will be deploying to, and hence do not know if the .NET Framework is preinstalled or not. For example, if you are an independent software vendor (ISV) developing and packaging your smart client application for sale to a wide variety of customers, you may not know whether or not your customers' computers have the .NET Framework installed.

To ensure that the .NET Framework is installed along with your application, you can use the setup.exe Bootstrapper sample. This sample checks to see if the .NET Framework has already been installed, and if it hasn't, the sample then installs the .NET Framework before installing the application.

For more information about using the setup.exe Bootstrapper sample, see Chapter 3 of Deploying .NET Framework-based Applications at https://www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2D-D03F-4B19-9025-6B87E6AE0DA6&displaylang=en.

Deploying Smart Client Applications

As you design your smart client applications, you should consider how those applications will be deployed. Wherever possible, you should try to minimize the system impact of any installation. Doing so allows you to keep closer track of any changes to the application and eases the problems of updating and uninstalling applications. However, sometimes you will need to perform more complex installations, for example when you are reusing unmanaged code components, or when you need to store sensitive data securely in the registry.

A number of options are available to you when deploying smart client applications. These include:

• No-touch deployment. With this approach, you copy the files to a Web server, and the .NET Framework will automatically download the application and its dependent assemblies to the client when the user clicks a link.
• No-touch deployment with an application update stub. With this approach, you use no-touch deployment to download an application stub, which then downloads the rest of the application to the local disk.
• Running code from a file share. With this approach, you copy the files to a file share and run the application from the share.
• Xcopy. With this approach, you copy the files directly to the client. The .NET Framework allows the application and all of its dependent assemblies to be located in a single directory structure, so you don't need to register anything on the client.
• Windows Installer packages. With this approach, you package your application's files in a Windows Installer package, and the package is then installed on the client.

Each approach has its own strengths and weaknesses. To help determine the most appropriate deployment approach for your environment, you should examine each in more detail.

No-Touch Deployment

No-touch deployment allows your users to access your application on a Web server by using a URL link to the application. To deploy an application by using no-touch deployment, you simply need to copy the appropriate files to the Web server. When a user browses to the location of the application by using a URL link, Microsoft Internet Explorer downloads and runs the application. The application and its dependent assemblies are downloaded to the client by using HTTP and are stored in a special location called the assembly download cache. When the .NET Framework determines whether or not an assembly on the Web server needs to be downloaded, only the date-time stamp on the file is checked, and not the assembly version number. If the assemblies on the server do not have a later date-time stamp than those on the client, they will not be downloaded.

If you use no-touch deployment to deploy your smart client applications, you need to provide the user with a URL to the location of the application on the Web server. With this approach, no installation program is necessary on the client computer — all code is downloaded as needed. Your application is automatically updated whenever changes occur on the Web server. If files have changed, the newer versions are downloaded as needed, just as with normal Web browsing.

No-touch deployment depends on the ability of the .NET Framework to interact with Internet Explorer 5.01 or later to check for .NET assemblies that are being requested. During a request, the executable file is downloaded to the download cache. A process named IEExec then launches the application in a secure isolated environment provided by the code access security infrastructure of the .NET Framework.

**Note   **The client will attempt to run the application only if it has both the .NET Framework and Internet Explorer version 5.01 or later installed.

If you decide to use no-touch deployment to deploy an application that uses application configuration files, you may need to configure the Web server directory to allow for the download of the application's configuration files, because this capability is not enabled by default. Be sure to enable configuration files to be downloaded only from the directory in which your application is located; otherwise, you may enable private configuration files to be downloaded and introduce a security risk.

**Note   **Configuration files are actually downloaded twice when no-touch deployment is used: the first time to check for binding information (for example, to control the exact versions of components that the application uses) and the second to look for user-specific configuration information.

You can use no-touch deployment from within an application that is already deployed to download and run code by using the Assembly.LoadFrom() method. This technique can be used to download code that changes frequently, such as business rules that change frequently, or to provide on-demand installation of some other functionality.

No-touch deployment allows you to run localized versions of the application. The current culture of the client computer is used to automatically download the appropriate resource assemblies required to provide a localized version of the application.

You can secure no-touch deployment applications by using the security mechanisms provided by the Web server. For example, to restrict access to the application to authorized users on an intranet, you can enable Windows Integrated Security on the application directory on the Web server. To allow all users to access the application, you can enable anonymous access to the application's directory.

**Note   **If your Web server does not allow anonymous access or use Windows Integrated Security to authenticate clients, your application may not be able to download the configuration file.

Limitations of No-Touch Deployment

No-touch deployment can be useful for deploying simple applications, or for deploying parts of a more complex application. However, it is not an appropriate deployment approach for the full installation of more complex smart client applications for the following reasons:

• Restricted default security settings
• Unreliable offline functionality
• No transacted installations

**Note   **The ClickOnce technology in version 2.0 of the .NET Framework will remove the need to manually make security policy changes to the client before the application is installed and run. ClickOnce will provide a configurable mechanism to allow security policy changes to be made automatically when the application is first installed from the Web server. ClickOnce will also provide reliable offline functionality to smart client applications and will allow them to be fully integrated with the Windows Shell.

• This section examines the restrictions of no-touch deployment in more detail.

Restricted Default Security Settings

Code access security grants permissions to the application according to the evidence that the application presents. By default, the application's location (the URL from where it was started) is used to determine the permissions that it is granted. Unless local security policy on the client computer is changed, no-touch deployment applications are partially trusted, which means that they are only granted a limited number of permissions.

By default, a smart client application deployed using no-touch deployment will not be able to do the following:

• Write to the hard disk (except to isolated storage)
• Deploy assemblies to the global assembly cache
• Deploy or use unmanaged code
• Deploy components that require registration or make other registry changes
• Integrate with the Windows Shell (specifically, the install icons on the Start menu and the Add or Remove Programs item in Control Panel)
• Access a database
• Interact with any other client applications, such as Microsoft Office applications
• Access Web services or other network-located resources that are not located on the same server on which the application is deployed
• Perform other security operations outside those defined in the zone associated with the deployment location

If your application requires more than the default set of permissions and you want to use no-touch deployment, you will have to modify the security policy on the client to grant the application the permissions to function properly. Such security policy changes need to be propagated to client computers before you deploy your application (for example, using Group Policy, a Windows Installer package, or a batch file). These requirements reduce some of the benefits of the no-touch deployment approach. For more information about deploying security policy, see ".NET Framework Enterprise Security Policy Administration and Deployment" at https://msdn.microsoft.com/en-us/library/13wcxx6y(VS.80).aspx.

As you design your applications, you should determine whether you can meet the design specifications of your smart client application and comply with the partial trust requirements of a no-touch deployment application. In general, no-touch deployment and running code from a file share offer solutions that are easy to deploy, but may restrict the functionality of the application to such an extent that they are impractical for many smart client applications. However, if your application does not require any additional permission, no-touch deployment may be an ideal deployment mechanism for your application.

For more information about fully trusted and partially trusted applications, see Chapter 5: Security Considerations.

Unreliable Offline Functionality

Another problem with deploying smart client applications using no-touch deployment is that they do not function reliably offline. This problem is due to a number of factors:

• Delayed downloading of assemblies. Assemblies are downloaded on demand and are stored in the assembly download cache, which is managed as part of the Internet Explorer cache. In some cases, when you run the application online, you may not download all parts of the application, which will affect the application's ability to function fully when offline.
• Assemblies may be deleted. Because the assemblies reside in an area managed by the Internet Explorer cache, if the cache is flushed for any reason, your application files will be deleted.
• Applications are dependent on Internet Explorer offline settings. When attempting to run an application offline, you must set Internet Explorer to run in offline mode, even though your application does not run within Internet Explorer. Also, if you do have connectivity, but Internet Explorer is inadvertently set to offline mode, no checks for updates will be made to the server.

No Transacted Installations

With no-touch deployment, assemblies are downloaded when required to a cache that can be flushed at any time. It is therefore not possible to be sure at any time that all of the necessary code is installed on the local disk. For many organizations, this uncertainty may be unacceptable for line-of-business applications.

No-Touch Deployment with an Application Update Stub

One of the main problems with using no-touch deployment is that, by default, the application runs from the assembly download cache, and under partial trust, unless the local security policy is modified. This can limit the functionality of your smart client application, including its ability to function reliably offline. One way to circumvent this problem is to use no-touch deployment initially to deploy an application stub, which in turn automatically downloads and installs the rest of the application to the local disk. The stub deploys the application to a specified location on disk, such as "C:\Program Files", and is therefore not subject to the limitations of the Internet Explorer cache. When the application is run, it will be granted full trust permissions because it is being run from the local disk, and can operate without the restrictions associated with partial trust applications. An application update stub can also be used to ensure that the application is reliably and automatically updated if changes occur on the server.

If you use this method to deploy your application, you need to ensure that the .NET Framework security policy of the client computer is modified to allow the application stub itself to run with sufficient permissions to download and store the application artifacts on the local disk.

Designing application update stubs can be complex. To help you, Microsoft has created the Updater Application Block, which you can use as a basis for designing your own automatic updates solution. The Updater Application Block is designed to:

• Implement a pull-based update solution for .NET Framework applications.
• Use cryptographic validation techniques to verify the authenticity of application updates before applying them.
• Perform post-deployment configuration tasks without user intervention.
• Help you write applications that automatically update themselves to the latest available version.

The architecture of the Updater Application Block is shown in Figure 7.1.

Figure 7.1   Updater Application Block architecture

For more information about the Updater Application Block, see "Updater Application Block for .NET" at https://msdn.microsoft.com/en-us/library/ms978574.aspx.

No-touch deployment with an application update stub supports the transacted installation of your application. The Updater Application Block can help ensure that the application is installed successfully in its entirety. To perform a transacted installation, you will need to include code that, in addition to performing the automatic updates, checks to see that all code has been installed on the local disk. This code can be in the form of a manifest file along with code that determines that each file in the manifest is on the local disk.

Combining no-touch deployment with an application update stub gives you many of the benefits of simplified deployment and updates as well as the ability to run your application in a fully trusted environment. Such benefits make this hybrid approach a useful choice for the deployment of many smart client applications. However, it is not the ideal choice in all situations. You still need to grant the application stub sufficient permissions to allow the stub to download the rest of the application. Also, applications installed using this approach do not provide Windows Shell integration (specifically, integration with the Start menu or the Add or Remove Programs item in Control Panel) unless you build this functionality into the application stub. Finally, the deployment and updates will only occur under the security context of user. This restriction can cause problems if your application needs to write to the registry, or to a part of the file system that you secure from the user.

Running Code from a File Share

Running code from a file share is similar to no-touch deployment, except that you provide users with a file share, rather than a URL, from which to deploy and run the application. Code run from a file share is downloaded on demand and is executed as appropriate. Because the code is running from the network, it runs as a partially trusted application, generally running from the local intranet and receiving the local intranet permission set, unless you change the security policy on the client.

Running code from a file share has many of the advantages and disadvantages of no-touch deployment, although the code is not cached on the client as it is with no-touch deployment. Because of the security restrictions associated with running code from a file share, it is often not appropriate for deploying smart client applications.

**Note   **As with no-touch deployment, you can adopt a hybrid approach that combines running code from a file share with an automatic update stub. For more information, see "No-Touch Deployment with an Application Update Stub" earlier in this chapter.

Xcopy Deployment

Xcopy deployment entails copying all of the files that the application consists of to the client computer so that the application can be run. Smart client applications often just consist of one or more executable files, one or more DLLs, and one or more configuration files located in a directory hierarchy. By copying all of these files to another computer, you essentially install the application. To uninstall the application, you just remove all of the files from the computer.

In situations where you only need to modify the file system to install the application, the Xcopy approach may be the best option. However, because you do not have programmatic control over the installation process, the Xcopy approach does not allow you to do the following:

• Deploy assemblies to the global assembly cache (and maintain references)
• Deploy COM objects
• Deploy components that require registration or make other registry changes
• Integrate with the Windows Shell

If your application requires additional installation steps, you may be able to perform these steps manually after copying the files. For example, if you need to modify the registry, you can edit the registry on your target computer or import *.reg files to ensure that the appropriate settings are in place. If you need to deploy assemblies to the global assembly cache, you can use 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.

**Note   **You can also use a drag-and-drop operation in Windows Explorer to move shared assemblies into the Global Assembly Cache folder. However, you should avoid this method because it does not implement reference counting. Without reference counting, the uninstall routine of another application can cause an assembly required by your application to be removed from the global assembly cache.

Xcopy deployment is suitable for some smart client applications, but in many cases the additional steps required to get the application to function properly makes this seemingly simple approach too laborious.

Windows Installer Packages

You can package your application for installation as a Windows Installer package. This approach gives you the unrestricted ability to install anything on the target computer, although the application is limited at run time by the security context of the end user installing the application.

Windows Installer packages are very flexible and powerful, so you can use them to install very complex applications that make a large number of configuration changes to the client. However, they are also appropriate for applications with much simpler installation requirements. Even if you have designed your application to have minimal impact on the client when installed, you should consider using Windows Installer packages, because they integrate with the Windows Shell by adding icons on the Start menu and desktop and adding the application to the Add or Remove Programs item in Control Panel. This integration allows you to control the installation effectively and uninstall the application when required.

You can add any or all of the following to a Windows Installer package:

• Project output groups
• Services files and folders
• Assemblies
• Application resources
• Merge modules
• CAB files
• Dependencies
• Registry settings
• Project properties
• Custom actions
• User interface design settings

After you have created a Windows Installer package, you have a number of options for distributing it to the client computer, including:

• Using enterprise push technologies such as SMS.
• Using the Group Policy functionality of Active Directory to publish or assign the packages.
• Allowing users to install the package from media, a file share, or a URL.

Using a push technology to install your Windows Installer packages allows you to have some centralized control over when and where the installation occurs. It also allows you to control which groups within the enterprise should have the application, or particular versions of the application. You can, for example, ensure that the installation occurs at a particular time of day for a particular group of users. However, bear in mind that you may require significant hardware and network bandwidth, depending on the size of your applications, to ensure that large-scale deployments work effectively.

One of the most significant advantages of a Windows Installer package is that if you use Group Policy or SMS, you can install the application without the user requiring administrative permissions. Windows Installer packages also automatically support transacted installations. Either all of the files and configuration changes will be installed by a Windows Installer package, or, if there is a problem, the installation will be rolled back in its entirety by Windows Installer.

The flexibility of the Windows Installer package means that it can be appropriate for installations of any complexity, from applications that simply write to the file system and integrate with the Add or Remove Programs item in Control Panel, to those that make many significant configuration changes to the client.

**Note   **If you use Windows Installer packages to deploy your application; you do not have to use the same method to deploy updates. In many cases it is preferable to design your application to automatically update itself after it is installed. For more details about configuring your applications for automatic updates, see "Automatic Updates" later in this chapter.

Choosing the Right Deployment Approach

With so many deployment choices available for smart client applications, it can be challenging to determine the correct choice for your environment. However, the requirements of your application and the needs of your users will normally determine the best approach.

The following table summarizes the features of each deployment approach.

Table 7.1   Deployment Approaches for Smart Client Applications

	No touch deployment	No-touch deployment with application update stub	Running code from a file share	Xcopy deployment	Windows Installer package
Reliable offline access	No	Yes	No	Yes	Yes
Full trust application functionality	Requires client security policy changes	Yes	Requires client security policy changes	Yes	Yes
Non-power user installation	Yes	Depends on requirements of application	Yes	Yes	Depends on requirements of application and application distribution mechanism
Low system impact	Yes	Depends on requirements of application	Yes	Yes	Depends on requirements of application
Windows Shell integration	No	No	No	No	Yes
Unrestricted installation	No	No	No	No	Yes
Transacted installation	No	Yes	No	No	Yes
Need to modify .NET Framework security policy of the client	Yes - if client needs to run under elevated permissions	Yes - for application stub only.	Yes - if client needs to run under elevated permissions	No	No

In many cases the simplest approach is to package your application using a Windows Installer package. Windows Installer packages are highly flexible and allow you to install applications of any complexity. If you use an enterprise push technology such as Group Policy or SMS to deploy your Windows Installer package, you can also install the applications under an administrative security context, regardless of the security context of the user. No-touch deployment with an automatic update stub is also a viable option when you want to allow your users to install their application by clicking a URL, but you will have to make changes to the local security policy of the target computer to ensure that your application stub application can run under full trust.

Deploying Smart Client Updates

After you have initially deployed your smart client applications, your work is not done. The applications will need to be updated over time, as you upgrade application functionality and fix bugs or address security vulnerabilities.

Depending on the situation, you may or may not use the same approach to update a smart client application as you used to deploy it. For example, if you initially deploy an application using a Windows Installer package, you may use automatic updates to deploy updates. The specifics of your environment will often determine which update methodology is most appropriate.

One common requirement when deploying updates is the ability to federate the update infrastructure, so that updates do not run off a single server or server farm controlled by a single entity. For example, if an ISV has created a smart client application that is deployed across a customer's enterprise, and the ISV releases an update for the application, the enterprise may want to download and test that update in their standard operating environment before it is propagated to all computers running across the enterprise. Federating the update infrastructure makes it possible to do so. For example, an update server could exist on the customer site that is responsible for obtaining updates from the ISV. The clients running within the enterprise would obtain the updates from the local update server, but only when the IT administrators approved it. This approach can also be used to increase the performance and scalability of the update infrastructure by relieving load of a single server or server farm.

When deploying updates to an application, you have the following options:

• No-touch deployment. The updated assemblies are added to the Web server for automatic download by the clients.
• Automatic updates. The application is configured to automatically download and install updates from a server.
• Updates from a file share. The updated assemblies are added to a network share for automatic download by the clients.
• Xcopy updates. The updates are copied directly to the clients.
• Windows Installer package deployment. The Windows Installer package is updated, a new package is created, or a patch package is used to update the client.

It is useful to examine each of the options in more detail so that you can determine which is most appropriate for your environment.

No-Touch Deployment Updates

If you have used no-touch deployment to deploy a simple application or parts of a more complex application, you can update these assemblies simply by placing the new files on the Web server. Before an assembly is loaded by the application, the .NET Framework automatically checks the time stamp of the assembly locally and on the Web server to see whether the assembly needs to be downloaded again, or whether the assembly can simply be run from the user's assembly download cache.

**Note   **No-touch deployment has a number of restrictions that make it unsuitable for deploying most smart client applications. For more details, see "No-Touch Deployment" earlier in this chapter.

Although issuing updates using a no-touch deployment method is generally very straightforward, your clients can have problems during an upgrade due to the lack of support for transacted installations. If you update the directory while clients are using the application, a client might download old code initially and then attempt to download other code that has since been updated. This can lead to unpredictable results and may cause your application to fail. The simplest solution to this problem is to deploy any significant updates to a separate directory on the Web server, and when deployment is complete, to change any links to the new location.

**Note   **If you choose to deploy your application using no-touch deployment with an automatic update stub, see the following section, "Automatic Updates."

Automatic Updates

In most cases, the best approach for patching, repackaging, and updating applications is to build the updating infrastructure into the application itself. In this case, the client application can be designed to automatically download and install updates from a server, and the IT administrator releases these updates to the server for clients to obtain. To achieve this, you can include code with an application so that the application does the following:

• Automatically checks for updates.
• Downloads updates if available.
• Upgrades itself by applying those updates.

As you configure your application for automatic updates, it is important to ensure that all of the updated files are downloaded to the client. This is particularly important when you update strong-named assemblies. Assemblies that call strong-named assemblies must specify the version of the strong-named assembly, so if you update strong-named assemblies, you must also update any assemblies that call them.

When configuring transacted updates, you can use code to check that the updates are installed locally, verifying them against a manifest. Often you will decide to install the update in a separate directory, and then either remove the original directory after a successful installation, or leave the original directory in place to provide a fallback application.

For more details about automatic updates and the use of the Updater Application Block, see "No-Touch Deployment with an Application Update Stub" earlier in this chapter.

**Note   **Automatic updates will be simplified with the ClickOnce feature in version 2.0 of the .NET Framework. As part of a deployment manifest, you will be able to specify whether and when the application should check for updates, along with an alternate update location.

Updates from a File Share

When you copy assemblies to a file share, those assemblies are downloaded to the client each time the application runs and are not cached. As with no-touch deployment, updating an application that was originally deployed by running code from a file share is simply a matter of adding the new code to the file share. The client then downloads the new code the next time it runs.

Xcopy Updates

If you originally distributed your application using a file copy technique, you may want to deploy updates in the same way. Regardless of the original deployment mechanism, though, file copy can be one of the most effective approaches for updating your application when the updates are relatively simple, such as modifications to a configuration file. In such cases, deploying an update is simply a matter of copying the new files and removing any old files that are no longer required.

Usually you can update private assemblies by simply copying the new version of the assembly over the old one. However, although you can use simple copy operations for the initial deployment of a strong-named assembly, it is not possible to update the strong-named assembly in this way and have your application (or other assemblies) use it automatically. The strong name of the assembly is stored in the manifest of any assembly that references it, and different versions of a strong-named assembly are considered to be completely separate assemblies by the common language runtime (CLR). Unless you specify otherwise, the CLR loads the same version of the strong-named assembly that your application was originally built against.

Windows Installer Updates

Windows Installer offers a comprehensive solution for updating .NET Framework applications. Several of its features are specifically designed to solve application update problems.

Windows Installer packages have built-in support for version control. If you version your application correctly, the Windows Installer package can automatically ensure that the update happens correctly, and you can specify whether previous versions of the application are to be removed when the new application is installed.

If you are using a push technology, such as SMS, to deploy these updates, you can also control which users receive updates and when they receive them. This feature is particularly useful if you are testing updates with a particular group of people before deploying the updates more extensively.

If you plan to upgrade your application using Windows Installer technology, you have three choices for implementing the upgrade:

• Build a patch package (.msp) and apply it to the currently installed application.
• Update the existing Windows Installer file.
• Create a completely new Windows Installer file.

In general, if you are going to use Windows Installer to deploy updates, you should use either use a patch package or update the existing Windows Installer file. If you create an entirely new Windows Installer file, Microsoft Windows® will not recognize the package as an update, and the upgrade management features of Windows will not function properly. However, in some cases, the changes are so extensive that you may choose to forego this functionality and create a new Windows Installer file.

**Note   **For more information about deploying updates using Windows Installer, see Deploying .NET-Framework-Based Applications at https://www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2D-D03F-4B19-9025-6B87E6AE0DA6&displaylang=en.

Choosing the Right Update Approach

In some cases, the update approach you choose is defined by the deployment approach you chose for your application. However, the most appropriate approach is often determined by the nature of the updates that you are deploying. For example, you may just be copying new files over old ones, or you may want the updated application to run alongside the old one. The update may involve adding new assemblies to the global assembly cache or changing configuration information in the registry. The updates are further complicated if you are deploying updates to strong-named assemblies, because each assembly that calls the strong-named assembly will use the version number in the call.

Table 7.2 summarizes the options available for updating your applications and the features that each support.

Table 7.2   Update Approaches for Smart Client Applications

	No-touch deployment updates	Automatic updates with an application update stub	Updates from a file share	Xcopy updates	Windows Installer updates
Non-power user update	Yes	Depends on requirements of application	Yes	No	Depends on requirements of application and application distribution mechanism
Centralized management of updates	Yes	Yes	Yes	No	Depends on application distribution mechanism
Updates downloaded when application is run	Yes	Yes	No	No	No
Federated update infrastructure	No	Yes	No	No	Yes
Per user/group updates	Yes	Yes	No	No	Depends on application distribution mechanism
Transacted updates	No	Yes	No	No	Yes
Built-in support for version control	No	No	No	No	Yes

In many cases, automatic updates are the most effective approach for deploying updates for your application. However, when deploying major updates, or updates that involve complex configuration changes to the client, you may need to use Windows Installer, which also has the benefit of automatic version control support.

Summary

Deploying smart client applications is much easier than deploying rich client applications was in the past, due to the features of the .NET Framework. However, there are a number of important choices you need to make for successful deployment, both in how you design your application for easy deployment, and in which deployment approach you choose for the application and for the .NET Framework itself.

In most cases, the best choice for deploying the application is either to use a Windows Installer package, or to use a combination of no-touch deployment and an application update stub. You will need to consider how to maintain the application and deploy updates effectively after it is deployed. Again, in most cases, the best choice is likely to be either Windows Installer, or automated updates, controlled by the application itself.

© Microsoft Corporation. All rights reserved.