I was playing with ClickOnce which is new in Visual Studio 2005 and thought it was pretty cool. Basically, ClickOnce is a deployment technology that enables self-updating Windows applications that can be installed and run with minimal user interaction.

ClickOnce applications can be self-updating; they can check for newer versions as they become available and automatically replace any updated files. You can specify the update behaviour; an administrator can also control update strategies, (e.g. making an update mandatory). Updates can also be rolled back to a previous version by the end user or administrator.

ClickOnce deployment overcomes three major issues inherent in deployment:

  • Difficulties in updating applications - earlier any time an application is updated, the user must reinstall the entire application; now the updates can be provided automatically, and only those portions of the application that have changed will be reinstalled.
  • Impact to the user’s computer - till now, applications often rely on share components with the potential for versioning conflicts; now, each application is self-contained and cannot interfere with other applications.
  • Security permissions - Windows Installer deployment requires administrative permissions; but now non-administrative users can install and grant only those permissions necessary for the application.

How does it work?

The core ClickOnce deployment architecture is based on two XML manifest files,an application manifest and a deployment manifest.

  • The application manifest (created using mage.exe) describes the application itself, including the assemblies, dependencies and files that make up the application, the required permissions, and the location where updates will be available.
  • The deployment manifest (also generated using mage.exe) describes how the application is deployed, including the location of the application manifest and files and the version of the application that clients should run.

After a deployment manifest is created, it is copied to the deployment location which can be a Web server, network share, or even a CD/DVD. The application manifest (and all application files) are also copied to a deployment location that is specified and this can be the same as the deployment location or different.

The users can download and install the application as simply as clicking an icon pointing to the deployment manifest file on a Web page or in a folder. In most cases, the user will be presented with a simple dialog box asking the user to confirm installation (including elevated permissions if needed), then installation will proceed and the application will be launched without further intervention.

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!

When the application developer creates an updated version of the application, he/she also generates a new application manifest and copies files to a deployment location. The administrator updates the deployment manifest to point to the location of the new version of the application.

Also, the deployment manifest also contains an update location (a Web page or network file share) where the application will check for updated versions. You can set properties to specify when and how often the application should check for updates. Update behaviour can be specified in the deployment manifest, or can be presented as user choices in the application’s user interface by means of the ClickOnce APIs. The, Publish properties can be employed to make updates mandatory or to roll back to an earlier version.
 


Icon for the sample application in the Start menu


The test application running locally after being installed


During the deployment, specifying the location where this would reside. Look at the examples which give you an idea on the various distribution strategies.


What is the target “platform“?


Where to check for updates?


Use a key for signing


Summary Screen


Screen shot of the deploy location. You can see various versions of the sample application present and also the dependencies (such as the .net runtime).


When the user starts an application and an update exists the user is prompted to either install it or skip it.


Snapshot of the registry that shows how the application version is tracked, etc. Here you can see the packages installed along with their versioning detail.

I will probably have more meaningful posts on this when I had a chance to use it in the “real world”.