ClickOnce Deployment Overview
ClickOnce is a deployment technology that allows you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment overcomes three major issues inherent in deployment:
Difficulties in updating applications. With Microsoft Windows Installer deployment, whenever an application is updated, the user must reinstall the entire application; with ClickOnce deployment, you can provide updates automatically. Only those portions of the application that have changed are downloaded, then the full, updated application is reinstalled from a new side-by-side folder.
Impact to the user's computer. With Windows Installer deployment, applications often rely on shared components, with the potential for versioning conflicts; with ClickOnce deployment, each application is self-contained and cannot interfere with other applications.
Security permissions. Windows Installer deployment requires administrative permissions and allows only limited user installation; ClickOnce deployment allows non-administrative users to install and grants only those Code Access Security permissions necessary for the application.
In the past, these issues sometimes caused developers to decide to create Web applications rather than Windows-based applications, sacrificing the rich user interface and responsiveness of Windows Forms for ease of installation. With applications deployed using ClickOnce, you can have the best of both technologies.
What is a ClickOnce Application?
Simply stated, a ClickOnce application is any Windows Presentation Foundation, Windows Forms, or console application published using ClickOnce technology. You can publish a ClickOnce application in three different ways: from a Web page, from a network file share, or from media such as a CD-ROM. A ClickOnce application can be installed on an end user's computer and run locally even when the computer is offline, or it can be run in an online-only mode without permanently installing anything on the end user's computer. For more information, see Choosing a ClickOnce Deployment Strategy.
ClickOnce applications can be self-updating; they can check for newer versions as they become available and automatically replace any updated files. The developer can specify the update behavior; a network administrator can also control update strategies, for example, marking an update as mandatory. Updates can also be rolled back to a previous version by the end user or by an administrator. For more information, see Choosing a ClickOnce Update Strategy.
Because ClickOnce applications are inherently isolated, installing or running a ClickOnce application cannot break existing applications. ClickOnce applications are completely self-contained; each ClickOnce application is installed to and run from a secure per-user, per-application cache. By default, ClickOnce applications run in the Internet or Intranet security zones. If necessary, the application can request elevated security permissions. For more information, see ClickOnce Deployment and Security.
How ClickOnce Deployment Works
The core ClickOnce deployment architecture is based on two XML manifest files: an application manifest and a deployment manifest.
The application manifest describes the application itself, including the assemblies, the dependencies and files that make up the application, the required permissions, and the location where updates will be available. The application developer authors the application manifest by using the Publish Wizard in Visual Studio 2005 or the manifest generation tool (Mage.exe) in the .NET Framework SDK. For more information, see How to: Publish a ClickOnce Application.
The deployment manifest describes how the application is deployed, including the location of the application manifest, and the version of the application that clients should run. An administrator authors the deployment manifest using the manifest generation tool (Mage.exe) in the .NET Framework SDK.
.gif) Note |
|---|
The Publish Wizard in Microsoft Visual Studio 2005 also generates a deployment manifest. |
After it is created, the deployment manifest is copied to the deployment location. This can be a Web server, network file share, or media such as a CD. The application manifest and all of the application files are also copied to a deployment location that is specified in the deployment manifest. This can be the same as the deployment location, or it can be a different location. When using the Publish Wizard in Microsoft Visual Studio 2005, the copy operations are performed automatically.
| Note |
|---|
If the developer is also the administrator (this is, has Administrator privileges for the Web site or file share where the deployment manifest will be deployed), this manifest is all that is required. If the developer is not the administrator, the administrator must use the command-line tool to update and sign the manifest. |
After it is deployed to the deployment location, end users can download and install the application by clicking an icon representing the deployment manifest file on a Web page or in a folder. In most cases, the end user is presented with a simple dialog box asking the user to confirm installation, after which installation proceeds and the application is launched without further intervention. In cases where the application requires elevated permissions, the dialog box also asks the user to grant permission before the installation can continue.
The application is added to the user's Start menu and to the Add/Remove Programs group in the Control Panel. Unlike other deployment technologies, nothing is added to the Program Files folder, the registry, or the desktop, and no administrative rights are required for installation
| Note |
|---|
It is also possible to prevent the application from being added to the Start menu and Add/Remove Programs group, in effect making it behave like a Web application. For more information, see Choosing a ClickOnce Deployment Strategy. |
When the application developer creates an updated version of the application, he or she also generates a new application manifest and copies files to a deployment location—usually a sibling folder to the original application deployment folder. The administrator updates the deployment manifest to point to the location of the new version of the application.
| Note |
|---|
The Publish Wizard in Microsoft Visual Studio 2005 can be used to perform these steps. |
In addition to the deployment location, the deployment manifest also contains an update location (a Web page or network file share) where the application checks for updated versions. ClickOnce Publish properties are used to specify when and how often the application should check for updates. Update behavior can be specified in the deployment manifest, or it can be presented as user choices in the application's user interface by means of the ClickOnce APIs. In addition, Publish properties can be employed to make updates mandatory or to roll back to an earlier version. For more information, see Choosing a ClickOnce Update Strategy.
ClickOnce and Windows Installer Comparison Table
The following table compares the features of ClickOnce deployment with Windows Installer deployment:
| Feature | ClickOnce | Windows Installer |
|---|---|---|
Automatic update1 |
Yes |
Yes |
Post-installation rollback2 |
Yes |
No |
Update from Web |
Yes |
No |
Does not affect shared components or other applications |
Yes |
No |
Security permissions granted |
Grants only permissions necessary for the application (more safe) |
Grants Full Trust by default (less safe) |
Security permissions required |
Internet or Intranet Zone (Full Trust for CD-ROM installation) |
Administrator |
Application and deployment manifest signing |
Yes |
No |
Installation-time user interface |
Single prompt |
Multipart Wizard |
Installation of assemblies on demand |
Yes |
No |
Installation of shared files |
No |
Yes |
Installation of drivers |
No |
Yes (with custom actions) |
Installation to Global Assembly Cache |
No |
Yes |
Installation for multiple users |
No |
Yes |
Add application to Start menu |
Yes |
Yes |
Add application to Startup group |
No |
Yes |
Add application to Favorites menu |
No |
Yes |
Register file types |
No |
Yes |
Install time registry access3 |
Limited |
Yes |
Binary file patching |
No |
Yes |
Application installation location |
ClickOnce application cache |
Program Files folder |
Notes
1. With Windows Installer, you must implement programmatic updates in the application code.
2. With ClickOnce, rollback is available in Add/Remove Programs.
3. ClickOnce deployment can access HKEY_LOCAL_MACHINE (HKLM) only with Full Trust permission.
For more information, see Choosing a Deployment Strategy.
See Also
Tasks
How to: Publish a ClickOnce Application
Concepts
Choosing a ClickOnce Deployment Strategy
Choosing a ClickOnce Update Strategy
ClickOnce Deployment and Security
Choosing a Deployment Strategy