ClickOnce Publishing Process

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.
To create client business applications using current Microsoft technologies, see patterns & practices' Prism.

The first step in ClickOnce deployment is publishing the application. This means placing the application files on the deployment server and generating two manifest files associated with a ClickOnce publication: the deployment manifest, and the application manifest. The deployment manifest contains information about the publication, including the deployment provider URL, which indicates where the application will be launched from; the update policy; and a reference to the application manifest. The application manifest contains the list of files that the application is composed of and the set of permissions required to run the application.

You can publish ClickOnce applications directly from Visual Studio 2010 by using an SDK tool named the Manifest Generating and Editing tool (Mage) or by using a custom tool that uses the ClickOnce publishing APIs. Visual Studio exposes most of the capabilities needed for ClickOnce publishing. However, Visual Studio might not be available to or desired by IT administrators who manage ClickOnce deployments on the server. Mage is designed to address most common administrative tasks for ClickOnce and is a lightweight .NET Framework Windows-based application that can be given to your administrators. However, it requires more steps, performed in the correct order, for common tasks such as modifying the application files listed in the application manifest. To make these tasks simpler, you can use a custom utility.

The Manifest Manager Utility sample utility included with this release uses the ClickOnce publishing API and enables you to manage deployment and application manifests in a simpler way. This tool is used for updating application manifest file lists and deployment manifest settings in the automated procedures described in the how-to topics.

Figure11 illustrates the typical structure of a ClickOnce application publication. It includes a root folder for the application, which contains the default deployment manifest (.application file). Under that folder is the Application Files folder, which contains a subfolder for each version of the application that is published. Each versioned folder contain the application manifest (.manifest file) for that version, the deployment manifest for that version (.application file), and all the application files (which have a .deploy file name extension). When you publish an application from Visual Studio, the default deployment manifest is updated to point to the application manifest for the most recent version published. Visual Studio also generates version-specific deployment manifests in the folder for that version; each deployment manifest points to its respective application manifest. This enables you to easily perform a server-side rollback of the application to an earlier version by simply replacing the default deployment manifest with a previous version-specific deployment manifests. Additionally, Visual Studio generates a Setup.exe file for the bootstrapping application and an optional Publish.htm test deployment page in the root folder when it publishes the application. The Setup.exe file installs any prerequisites, and then calls the ClickOnce deployment manifest to install the application.


Figure 1

ClickOnce publish folder structure

If you manually generate or update a ClickOnce application publication by using either Mage or a custom tool, you are not restricted to this folder and file structure. For any ClickOnce publication, the chain of dependencies includes the following:

  • A deployment manifest that points to itself or to another deployment manifest through the embedded deployment provider URL. (ClickOnce supports a one-hop redirect through this URL.)
  • A deployment manifest that points to the application manifest through an embedded code base URL.
  • An application manifest that contains relative paths to each of the application files. These files must reside in the same folder or a subfolder in which the application manifest resides.
  • The application files themselves, usually with a .deploy file name extension appended to the file name to simplify mapping these files to MIME types on the deployment server. ClickOnce automatically strips off the .deploy file name extension on the client side after the file is downloaded.

There are several publishing scenarios that are often encountered with an automatic deployment mechanism such as ClickOnce. These scenarios include the following:

  • Broadcast deployment. A new version is placed on the deployment server and everyone starts downloading it immediately after it is published. This is the default approach of ClickOnce, but it can pose scalability challenges for large organizations. For more information about handling the server load for this scenario, see Handling High Deployment Server Load. Adopting the staged deployment or future deployment strategies can also help alleviate this scalability problem.
  • Staged deployment. A new version is placed on the deployment server, but different groups are expected to download the update at different times. For example, in a bank branch scenario, Branch A might be expected to do its updates on Monday, Branch B on Tuesday, Branch C on Wednesday, and so on. This would require each branch to use a different launch URL for its application so that separate physical installations are present on the client computer.
  • Future deployment. A new version is available, but it needs to be applied at a specific time in the future. For example, you might want all client computers to start using the new version at 9:00 A.M. Monday morning when the new server components that the client computer will communicate with are activated. In this scenario, you will need to allow client computers to download and cache the new software version ahead of time so that the switch to the new version can be done at a specific time that is not affected by deployment server loading. For more information, see How to: Apply Updates at a Future Time.