Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Introduction to the Updater Application Block

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

Introduction to the Updater Application Block

Updater Application Block - Version 2.0

patterns & practices Developer Center

Microsoft Corporation

March 2005

Summary: This introduction chapter to Updater Application Block provides the audience requirements, highlights of this release and system requirements for successfully using it.

Contents

Scenarios and Design Goals

Simplifying the Addition of Self-Updating Capabilities

Designing for Efficient Use of Network Bandwidth

Designing for Simple Migration to ClickOnce

Designing for Processing of Complex Updates

The Updater Application Block is a .NET Framework component that you can use to detect, download, and apply client application updates deployed in a central location. By using the Updater Application Block, you can keep smart client applications up to date with little or no user intervention. You can also extend the Updater Application Block to use custom classes for downloading files and for performing post-deployment configuration tasks.

Specifically, the Updater Application Block helps you in the following ways:

  • It helps you implement a "pull model" for automatically downloading updates for .NET Framework applications.
  • It helps you perform post-download configuration tasks without requiring user intervention.
Note   This application block for .NET has been designed based on reviews of successful .NET Framework applications. It is provided as source code that you can use "as-is" or customized for your application. It is not an indication of future direction for application deployment within the Microsoft .NET Framework. Future releases of the .NET Framework may use a different model to address application deployment.

Audience Requirements

This guide is intended for software architects and software developers. To benefit fully from this guide, you should have an understanding of the following:

  • Microsoft Visual C# or Microsoft Visual Basic
  • .NET Framework 1.1
  • XML
  • Internet Information Server
  • Windows Forms

Highlights of This Release

This release of the Updater Application Block, version 2.0, includes the following new features:

  • Simplified public APIs
  • Separation of concerns: Manifest, downloader, and activation with extensibility points at appropriate levels
  • Support for partial updates
  • Support for multiple types of downloader
  • Events to enable the application to perform any custom processing at key stages of the update process
  • Support for using events to monitor download progress
  • Support for updates based on Microsoft Windows Installer technology
  • Activation processors for commonly required post-download activation tasks
  • A graphical tool for managing configuration settings based on Enterprise Library
  • Adherence to the patterns and practices Enterprise Library specification

Migrating from Earlier Versions of the Updater Application Block

The survey results from the earlier releases of the Updater Application Block indicate that usability was one of the key areas for enhancement. To address this, the application block has been significantly reengineered to simplify the public APIs and clearly separate the functionality with extensibility points. This version has scenario compatibility with version 1.0; however, when migrating from version 1.0 to version 2.0, you will need to familiarize yourself with the newly designed API. Version 2.0 of the Updater Application Block also includes QuickStarts with walkthrough documentation for each one. For more information about the walkthroughs, see QuickStarts.

System Requirements

The Updater Application Block requires the following software:

  • Windows XP Professional
  • Internet Information Server version 5.0 or later
  • Microsoft .NET Framework version 1.1 SDK
  • Microsoft Visual Studio 2003
  • Background Intelligent Transfer Service (BITS) (for the out-of-the-box downloader to function correctly)

The application block has been tested using this configuration and cannot be guaranteed to function correctly in other environments.

Updater Application Block Dependencies

The Updater Application Block depends on other application blocks and code included in the patterns & practices Enterprise Library for configuration, hashing, and logging functionality. The Updater Application Block uses the following functionality from the Enterprise Library:

  • It uses the Configuration Application Block to read its configuration information.
  • It uses common library functionality, such as instrumentation, which provides various functions for exposing events and data used for system management.
  • It uses the Enterprise Library Configuration Console to modify configuration information stored in XML files.
  • It uses the Cryptography Application Block to create and compare the file hash in the manifest.
Note   The Updater Application Block requires that you also install the Enterprise Library Cryptography Application Block. The Enterprise Library can be downloaded from http://msdn.microsoft.com/library/en-us/dnpag2/html/entlib.asp. The Enterprise Library Configuration Application Block and common library functionality are installed with the Cryptography Application Block

Updater Application Block Documentation

In addition to this introduction, the documentation contains the following topics:

  • Design of the Updater Application Block. This explains the decisions that went into designing the application block and the rationale behind those decisions.
  • Developing Applications with the Updater Application Block. This explains how to install and use the application block. It describes the common scenarios for using the application block and how to write the code for each of these scenarios.
  • Extending the Updater Application Block. This describes how to extend the application block by adding your own downloader and activation providers.
  • Deployment and Operations. This explains how to deploy and update the application block's assemblies. It also contains information about configuration and security.
  • QuickStarts. This explains how to install and configure the QuickStart applications. It also contains a series of walkthroughs that demonstrate how to incorporate common client application update operations into an application.

More Information

For more information, see the following patterns & practices guides:

The GotDotNet community site provides a place for .NET developers to share code and ideas. A GotDotNet workspace for the Updater Application Block has been created at http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5 [Content link no longer available, original URL:http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5]. Please share your Updater Application Block questions, suggestions, and customizations with the community in this workspace.

Scenarios and Design Goals

The Updater Application Block is designed to support the most common scenarios for self-updating applications:

  • It supports applications that need to be kept up-to-date with current versions.
  • It supports applications that use multiple plug-ins that users can download and activate on their desktops.
  • It supports applications that rely on reference data (for example, a large set of documents) that need to be cached on the client and occasionally updated from a server.

The design of the application block supports these scenarios while providing a manageable and scalable solution that strikes a balance between flexibility and complexity. The main design goals of the Updater Application Block, version 2.0, are the following:

Alternatives to the Updater Application Block

A number of alternative technologies that provide similar functionality to the Updater Application Block are also available:

  • Application Updater sample. The Application Updater sample, available from Windows Forms .NET, includes a single solution with no extensibility points. You should consider using this sample if your application requires simple update functionality and you are using an operating system that does not support BITS.
  • ClickOnce. ClickOnce is a robust, platform solution provided in .NET Framework, version 2.0. The Application Updater Block is designed to enable simple migration to ClickOnce when it is available.

Simplifying the Addition of Self-Updating Capabilities

To maximize the usefulness of this application block to the developer community, the Updater Application Block should be easy to integrate into applications. This design goal translated into the following application requirements:

  • It should be easy to add the Updater Application Block to a new or existing application.
  • The Updater Application Block should work using the default configuration.

Design Implications

The design implications of these requirements for the application block are as follows:

  • It uses the Enterprise Library Configuration Console. This tool allows the application block configuration to be created by default and exposed through the Configuration Console. The Updater Application Block console extension lets you add the application block to your application; it sets default values for all the configuration information, removing the need to edit XML files manually just to get the application block working.
  • It includes the Manifest Editor tool, which you can use to easily create manifest files.
  • It includes the ApplicationUpdaterManager class, which acts as a facade into the application block. This simplifies the development effort required for default configuration applications.

Tradeoffs

The design decisions made during the development of the application block result in the following tradeoffs:

  • When creating custom download providers, the Enterprise Library Configuration Console requires the use of a design-time assembly for the configuration (Microsoft.ApplicationBlocks.Updater.Configuration.Design.dll). This increases the amount of code in the Updater Application Block but extends its usability. Also, when users create custom download providers, they will have to modify the design-time assembly to expose the custom download provider properties to the Configuration Console.
  • The Enterprise Library Configuration Console stores metadata concerning the Updater application block configuration in the main App.config file and the actual configuration information is stored in a file named Updaterconfiguration.config. This arrangement slightly increases the management of the project with the addition of the extra file.

QuickStarts

To learn more about how the application block is designed to be simple to add to applications, see the Manual InProc QuickStart and Auto InProc QuickStart.

Designing for Efficient Use of Network Bandwidth

It is essential that the solutions do not adversely affect other network or client applications. This design goal translated into the following requirements:

  • Updates should be successfully downloaded regardless of the bandwidth available.
  • The download process should not compete with client applications for network bandwidth.
  • Large updates and data should still be transferred even if the client application is closed.
  • The application block should be usable in environments where BITS is not supported.

Design Implications

The design implications of these requirements for the application block are as follows:

  • Download and activation state is stored in the task registry to enable resumption of tasks.
  • BITS is used as the default download technology.
  • Alternative download technologies are supported through the addition of custom downloaders. However, custom downloader implementations should be carefully developed to not block other client applications.

QuickStarts

The following QuickStarts demonstrate the use of the BITS downloader:

  • Auto InProc QuickStart
  • Manual InProc QuickStart
  • Simple AppStart QuickStart
  • MSI QuickStart
  • No-Touch Deployment QuickStart

Designing for Simple Migration to ClickOnce

Because many developers will want to migrate applications developed with Visual Studio .NET 2003 and the Updater Application Block to Visual Studio 2005, a simple way to migrate is important to the design of the application block. This design goal translated into the following application requirement:

  • The migration from a basic implementation of the Updater Application Block to ClickOnce should be a simple procedure.

Design Implications

The design implications of these requirements for the application block are as follows:

  • This requirement curtails the development of extensibility points that ClickOnce will not support. For example, the flexibility to obtain manifests from non-URL sources.
  • You can use policy processing to control which users or computers apply which updates to their applications. For example, you may want to ensure that only users in the Accounts department can apply a certain update. To adhere to the design of ClickOnce, this type of processing can occur only on the server, not on the client computer.

Tradeoffs

The design decisions made during the development of the application block result in the following tradeoffs:

  • The reduction of the extensibility of the application block simplifies the design; however, some developers may need to modify the application block code to achieve their objectives.
  • Despite a customer interest in client-side policies for updates, the application block adheres to the ClickOnce server-side policy processing design to ease the migration path.

Designing for Processing of Complex Updates

To maximize the usefulness of this application block, it should support complex processing of updates. This includes both complex file and path combinations for download and complex activation processing. This design goal translates into the following requirements for the application block:

  • It must provide an extensible architecture for actions to be performed after the update download.
  • It must provide the capability to download and install Windows Installer updates.
  • It must provide the capability to update components of an application that are being used by the application when the update process occurs.

Design Implications

The design implications of these requirements for the application block are as follows:

  • It supports simple configuration of the paths and files to be downloaded using the client application configuration files.
  • It supports the execution of more than one activation processor and includes a manager that controls the execution of the processors.
  • It includes a Windows Installer post-processor that you can use to execute complete installations and partial updates.
  • It supports file hash comparisons to enable partial updates.
  • It provides activation processors that can complete an activation process after the application is shut down.
  • It provides a non-transactional three-phase execution model for processors. In the initialization phase, each processor is initialized and code is executed to ensure that the requirements for the processor to execute are in place. If any processor is unable to run, the activation process is aborted. In the execution phase, each processor is run in the order defined in the manifest. If any processor fails, all processors are given the opportunity to perform corrective actions.

QuickStarts

The following QuickStarts demonstrate activation processing:

  • Auto InProc QuickStart
  • Manual InProc QuickStart
  • Simple AppStart QuickStart
  • MSI QuickStart
  • No-Touch Deployment QuickStart

Start | Previous | Next

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.