Deployment and Operations

Updater Application Block - Version 2.0

March 2005

Summary: This chapter describes various deployment scenarios of Updater Application Block.

There are several operational considerations for the Updater Application Block. This section includes the following topics:

Deploying the Updater Application Block

Configuring the Updater Application Block

Deploying the Updater Application Block

You can deploy the Updater Application Block on computers that are running Windows XP and later operating systems. Before deploying the Updater Application Block, you must install the Microsoft .NET Framework version 1.1.

You can deploy the whole Updater Application Block (including the source code, documentation, and QuickStarts) on a development workstation by running the ApplicationUpdater2.msi installation program. In production environments, you should use the following deployment method.

Preparing the Shared Update Location

Create a central server-based location application updates can be downloaded from. The specific kind of location (such as Web server or network share) depends on the downloader you intend to use. If you are using the default BITSDownloader supplied with the application block, your update location should be on a Web server. You can create a single location for all application updates or use a different location for each application. If you are publishing updates for multiple applications in a single location, you should generally use a subfolder for each application.

For each update, you must create a folder that contains the manifest file and the application updates. A good practice is to name the root folder after the application name and create a subfolder for the application updates named after the version number. For example, the root folder for MyApp should be named MyApp and the application updates for version 2.0.0.0 should be in a subfolder named 2.0.0.0.

Figure 5.1 shows a server deployment for two updateable applications.

Figure 5.1. Server deployment

For more information about creating the manifest file, see Create the Manifest File.

You can create custom activation processors that update the manifestUri attribute in the Updaterconfiguration.config file. This attribute defines the location of the manifest; changing it enables you to control the location of the next version of the update. This type of activation processor should be the last to run to avoid potentially unrecoverable conditions where errors occur in later processors and it is not possible to roll back the changes. An alternative to this technique is to use the MSIProcessor to manage versioning which will ensure that all roll-ups are installed.

Deploying the Client Application

You must also make sure that the locations specified in the configuration files, such as the reference to the Updaterconfiguration.config file in the App.config file and the manifestUri element in the Updaterconfiguration.config file, are valid for the deployed application.

You must include all these configuration files, the application block assemblies, and the client application files in the package that you install on the client computers:

• The Updater Application Block is implemented in three assemblies that must be shipped alongside the client application:
  • Microsoft.ApplicationBlocks.Updater.dll
  • Microsoft.ApplicationBlocks.Updater.ActivationProcessors.dll
  • Microsoft.ApplicationBlocks.Updater.Downloaders.dll
• The application block also uses the following assemblies from the Enterprise Library that must be installed on the client computers:
  • Microsoft.Practices.EnterpriseLibrary.Common.dll
  • Microsoft.Practices.EnterpriseLibrary.Configuration.dll
  • Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.dll (if using partial updates or the ValidateProcessor)

Applications that use the Updater Application Block can access the application block and Enterprise Library assemblies in one of two locations:

• As private assemblies in the application folder hierarchy
• As shared assemblies in the global assembly cache

Deploying the Updater Application Block as a Private Assembly

The Updater Application Block and Enterprise Library application blocks can be deployed in the application folder structure. This simplifies deployment because you can use the xcopy command to install the whole application on the client computer.

If multiple applications on the same computer use the application blocks, you can install a copy of the assemblies in each application folder hierarchy. This allows for each application's copy of the assemblies to be updated independently.

Deploying the Updater Application Block as a Shared Assembly

You can deploy shared assemblies in the global assembly cache. This enables all applications on the computer to use the assemblies without any additional configuration.

To install the Updater Application Block and Enterprise Library assemblies in the global assembly cache, you must first generate a strong name key, sign the assemblies, and the install them in the global assembly cache in the correct order.

After you install the assemblies in the global assembly cache, you will have to make changes to your application configuration files. These files reference the assemblies using their fully qualified assembly type names. If you are using assemblies installed in the global assembly cache, you must update these references to include the public key token associated with the installed version of the assembly.

For more information about installing assemblies in the global assembly cache, see the following:

• Deploying .NET Framework-based Applications
• Deploying Applications in the.NET Framework Developer's Guide

Configuring the Updater Application Block

There are three key sources of configuration information in an Updater Application Block-based solution:

• Application configuration file
• Updater application configuration file
• Manifest file

If you are using hash comparisons for partial updates or the ValidateProcessor for validation, you will also require a security configuration file, Enterpriselibrary.Security.Cryptography.config. For more information about this file, see the Enterprise Library documentation.

You can use the Enterprise Library Configuration Console to generate the application configuration, updater application configuration, and cryptography configuration files. For more information about using the Enterprise Library Configuration Console, see Configure the Client Application. You can use the Manifest Editor tool to generate the manifest file. For more information about using the Manifest Editor tool, see Create the Manifest File.

Because each of these files may contain sensitive information, such as user credentials for custom downloaders or folder paths, you should consider securing the files using Windows NTFS file system permissions. For more information about securing applications, see Securing Applications. Alternatively, you can use the Enterprise Library Configuration Console to encrypt the configuration sections. For more information about encrypting sections, see the Enterprise Library documentation.

Application Configuration File (App.config)

This file is used to specify the configuration settings that are used by the Enterprise Library Configuration Application Block to provide configuration information to the Updater Application Block at run time. The key configuration information in this file that is required by the Updater Application Block is the location of the updater application configuration file, Updaterconfiguration.config and the cryptography configuration file, Enterpriselibrary.Security.Cryptography.config.

The file should be named App.config and located in the same folder as the client application executable.

The following code sample shows a sample application configuration file.

<configuration>
  <configSections>
  <section name="enterpriselibrary.configurationSettings" type="Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationManagerSectionHandler, Microsoft.Practices.EnterpriseLibrary.Configuration" />
  </configSections>
  <enterpriselibrary.configurationSettings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" applicationName="SimpleQuickstart" xmlns="http://www.microsoft.com/practices/enterpriselibrary/08-31-2004/configuration">
    <configurationSections>
      <configurationSection xsi:type="ReadOnlyConfigurationSectionData" name="UpdaterConfiguration" encrypt="false">
        <storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="..\..\UpdaterConfiguration.config" />
        <dataTransformer xsi:type="XmlSerializerTransformerData" name="Xml Serializer Transformer">
          <includeTypes>
            <includeType name="BITSDownloaderProviderData" type="Microsoft.ApplicationBlocks.Updater.Configuration.BitsDownloaderProviderData, Microsoft.ApplicationBlocks.Updater.Downloaders" />
          </includeTypes>
        </dataTransformer>
      </configurationSection>
      <configurationSection name="securityCryptographyConfiguration">
        <storageProvider xsi:type="XmlFileStorageProviderData" name="Storage" path="..\..\EnterpriseLibrary.Security.Cryptography.config" />
        <dataTransformer xsi:type="XmlSerializerTransformerData" name="Transformer">
          <includeTypes />
        </dataTransformer>
      </configurationSection>
    </configurationSections>
    <keyAlgorithmStorageProvider xsi:nil="true" />
    <includeTypes />
  </enterpriselibrary.configurationSettings>
</configuration>
  

For more information about the application configuration file, see the Enterprise Library documentation.

Updater Application Configuration File (Updaterconfiguration.config)

This file is primarily used to specify the configuration required by the client application to identify the manifest location for the application.

The file should be named Updaterconfiguration.config and it should be stored in the location specified in the application configuration file.

The following code sample shows a sample updater application configuration file.

<?xml version="1.0" encoding="utf-8"?>
<UpdaterConfiguration>
  <xmlSerializerSection type="Microsoft.ApplicationBlocks.Updater.Configuration.ApplicationUpdaterSettings, Microsoft.ApplicationBlocks.Updater">
    <applicationUpdater xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" applicationId="215e1ad7-9aba-432f-a952-24baba556850" manifestUri="http://localhost/Updater2QuickStarts/cs/simple/server/manifests.xml" xmlns="urn:schemas-microsoft-com:PAG:updater-application-block:v2">
      <manifestManager username="" password="" authenticationMethod=""/>
      <downloaders>
        <downloader xsi:type="BitsDownloaderProviderData" name="BITSDownloader">
         <authenticationScheme>BG_AUTH_SCHEME_NTLM</authenticationScheme>
         <targetServerType>BG_AUTH_TARGET_SERVER</targetServerType>
        </downloader>
      </downloaders>
    </applicationUpdater>
  </xmlSerializerSection>
</UpdaterConfiguration>
  

For more information about the updater application configuration file, see Configuration Design.

Manifest

This file is used to specify information about an update process to the application block at run time. For example, you can specify the files to be downloaded and the activation processors to be used. It is stored on the server and accessed by the application block at the start of the update process.

The name of the file is not important, because the file is accessed using the location information stored in the updater application configuration file.

The following code sample shows a manifest file.

<manifest manifestId="{311085F7-9320-4318-9A67-9BE32F04E933}" mandatory="No" xmlns="urn:schemas-microsoft-com:PAG:updater-application-block:v2:manifest">
  <description>a description for this manifest</description>
  <application applicationId="215E1AD7-9ABA-432f-A952-24BABA556850">
    <entryPoint file="SampleClient.exe" parameters="" />
    <location>.</location>
  </application>
  <files base="http://localhost/Updater2QuickStarts/cs/simple/server/" hashComparison="No">
    <file source="manifests.xml" transient="No" />
    <file source="m2.xml" transient="No" />
  </files>
  <downloader name="BITSDownloader"/>
  <activation>
    <tasks>
      <task name="ApplicationDeployProcessor" type="Microsoft.ApplicationBlocks.Updater.ActivationProcessors.ApplicationDeployProcessor, Microsoft.ApplicationBlocks.Updater.ActivationProcessors"/>
    </tasks>
  </activation>
  <includedManifests>
    <manifest location="m2.xml" manifestId="{D31EDA46-B9A0-42cc-996D-684480F851B1}"/>
  </includedManifests>
</manifest>
  

For more information about the manifest file, see Manifest Schema Design.

Start | Previous | Next