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. |
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 from Visual Studio 2008 using a tool named the Manifest Generating and Editing tool (Mage) or a custom tool that uses the ClickOnce publishing APIs. Visual Studio exposes most of the capabilities needed for ClickOnce publishing. However, Visual Studio may not be available or desired for 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, Mage requires too many very detailed 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, a custom utility is needed.
The Manifest Manager Utility sample utility included with this release demonstrates how to use the ClickOnce publishing API 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 automated procedures for the How-to topics.
Figure 1 illustrates the typical structure for a ClickOnce application publication. It includes a root folder for the application, which contains the default deployment manifest (.application file). A subfolder is created for each version of the application that is published, and that folder contains the application manifest (.manifest file) for that version in addition to all the application files (suffixed with a .deploy file name extension). The default deployment manifest is updated to point to the application manifest for the most recent version published when you publish from Visual Studio. Visual Studio also generates version-specific deployment manifests in the root folder for each version published; each deployment manifest points to its respective application manifest. This allows you to easily perform a server-side rollback of the application to an earlier version by simply replacing the default deployment manifest with one of the version-specific deployment manifests. Additionally, Visual Studio generates a Setup.exe file for the bootstrapping application and a Publish.htm test deployment page in the root folder when it publishes.
Figure 1
ClickOnce publish folder structure
If you manually generate or update a ClickOnce application publication using either Mage or a custom tool, you are not constrained to this folder and file structure. For any particular ClickOnce publication, the chain of dependencies includes the following:
- It includes a deployment manifest that points to itself or another deployment manifest through the embedded deployment provider URL (ClickOnce supports a one-hop redirect through this URL).
- It includes a deployment manifest that points to the application manifest through an embedded code base URL.
- It includes an application manifest that contains relative paths to each of the application files. These files must reside in the same folder or a subfolder from where the application manifest resides.
- It includes 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 in the same time frame 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 may 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 point in the future. For example, you may 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 case, 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.
