any developers would love to leverage the rich UI, high performance, and offline capability offered by smart client applications; however, they've been turned off by the high TCO caused by client deployment headaches. The advent of ClickOnce client deployment technology in the .NET Framework 2.0 heralds a new era where client deployment takes on the ease and reliability of Web deployment.
This article is an overview of ClickOnce deployment designed to get readers acquainted with the new technology. I will take a peek under the hood to see what makes ClickOnce run, then bubble back up to talk about how to deploy applications and updates via ClickOnce, using tools such as Visual Studio 2005 and Mage.
Client deployment can be hard and expensive. First, you need to install the application to every client machine not only at the point of initial deployment, but also for every subsequent update to the application. Ensuring that your users are all in sync with the latest version of the application is also an expensive proposition. Then there's the risk that a client setup may break existing applications on the target machine.
ClickOnce works to remove these barriers to client deployment by delivering on the following principles:
|Figure 1: This progress dialog is displayed as the application files are downloaded and committed to the ClickOnce application store.|
- Touchless install. ClickOnce deployment has the mien of a Web installation. The application files are posted to a central location, and the end-user is presented with a URL pointing to this location. Upon execution of the link, the application files are downloaded on to the user's machine and the application runs immediately. During the interim between clicking the link and activation of the application, the user is shown progress UI, as in Figure 1.
- Auto-updates. ClickOnce-deployed applications update themselves. Once you have published a new version of the application to the update server, ClickOnce will detect the change and each client machine will be updated without additional effort on your part.
- Robust security model. ClickOnce introduces the concept of application-level security. That is, applications run within a default security sandbox. Stepping outside the sandbox boundaries requires explicit trust elevation by the user or an administrator.
- Reliable and scalable. Installation of a ClickOnce application is low-impact and isolated, so other applications on the target machine are not affected and system resources are not corrupted.
Early adoption of ClickOnce has shown that the technology can scale up to thousands of users without a decrease in service quality.
Mechanics of ClickOnce
Let's "geek out" for a bit and dive into how ClickOnce works behind the scenes. ClickOnce deployment does not involve an installation package. In fact, the whole shebang is driven by two manifests: the deployment manifest and the application manifest. As one would expect, the application manifest describes the application; that is, the files that make up the application and the application's security information. The deployment manifest contains information such as the version of the application being described and the semantics for checking for updates. As I'll show in a bit, with the help of Visual Studio 2005, you won't have to know much more about these two files.
|In order to deploy using ClickOnce, the .NET Framework 2.0 needs to be installed on the client machine. There are no such requirements for the host server.|
All the smarts to handle the application metadata stored in these manifests is baked into the .NET Framework 2.0. As part of the Framework's setup on the user's machine, a mime handler for the deployment manifest is installed. The deployment manifest is thus the activation point for the application. When the deployment manifest is activated (eg: via URL in the browser), the mime handler for this file type invokes the ClickOnce runtime in the .NET Framework 2.0, which then kicks off the installation of the application or checks for updates if the application is already installed. I think the best way to think of ClickOnce is that it's a manifest-driven deployment and update service for client applications, baked into the .NET Framework 2.0.
There are a few more details about how ClickOnce installs itself that are important to note. First, ClickOnce installation has little local impact; ClickOnce does not touch the Global Assembly Cache or Windows registry, for example. These restrictions are in place to ensure a reliable and non-breaking client installation on the target machine.
During a ClickOnce installation, the application files are downloaded into a per-user application store. In this location, applications are isolated from one another; furthermore, each user's application installs are isolated from other users on the same machine. The store is independent of the user's Internet browser cachein fact, it's managed separately, by the ClickOnce runtime.
Besides downloading files to a specific location, what more is done at install time? Depending on how the application is configured to be installed, ClickOnce allows for some integration with the Windows Shell.
There are two different ways that a ClickOnce application can be installed: online or offline. An online application has the feel of a true Web application in that the only way to activate the application is via the URL with the user connected to the network.
By contrast, the application installed as offline has some integration with the Windows Shell that allows it to be activated when the user is offline. At install time, a shortcut is inserted into the Start menu and an entry is added in the Add and Remove Programs list. This allows the user to uninstall the application and self-administer updates.