rom the simplest point of view, ClickOnce is a software technology from Microsoft that gives .NET developers the ability to publish complete applications (executable programs along with their resource and data files) to a Web server. ClickOnce creates “deployment packages” accessible to end users (clients) via a URL. A client request for that URL triggers an install process that deploys the application to the client’s machine.

In our quest to succinctly explore the riches of ClickOnce, we’re going to trip over a lot of the “exposed wires and cables” of this matrix. ClickOnce is a boundary-crossing technology?a new paradigm if you will?but I see it as more than just a deployment and update solution; it’s an important evolutionary step on the path to the inevitable ultimate fusion of what are now the “parallel universes” of Web (browser-based) development and “classic” desktop application development.

ClickOnce allows developers to build centralized applications that provide a per-user solution. Like Web applications, end users can download, install, and use these products without being logged in as administrators. They can obtain and use your products on-demand, because the applications are available online at any time.

ClickOnce didn’t arise from a vacuum; it evolved from earlier technologies. Brian Noyes, a software architect with iDesign, and author of a new book on ClickOnce says, “Some of the historical build up [for ClickOnce] was no-touch deployment in .NET 1.0…followed by the AppUpdater component from Jamie Cool as a proof of concept, followed by the Updater Application Block as an interim solution.”

In other words, ClickOnce emerged from a matrix of .NET?and earlier?technologies and concepts for publishing, deploying, and updating applications securely via the Net. Among its ancestors are:

• Internet or server-based deployment, installation, and updating technologies for applications, including the concept and implementation of “No Touch Deployment” and other models. Java Web Start is a non-Microsoft example of innovation in this area.
• Microsoft’s run-inside-the-browser solutions, first and foremost the security horror of embedded ActiveX controls.
• The split between thick and thin clients, both conceptually and as actual real-world solutions.
• “Rich” and/or smart clients, most recently those enabled by the Windows Presentation Foundation. It’s important to remember that smart clients are not restricted to WPF, they can also be Windows Forms, VSTO applications, smart device mobile applications, etc.
• Various .NET 1.0~2.0 technologies intended to simplify updating applications, such as Microsoft’s Application Updater Block.

ClickOnce is also more than just an “escape route” from the DLL hell often created by earlier deployment efforts; it’s an attempt to make the Internet, an intranet, a network share, or a CD an easy-to-use installation and update source for .NET applications. ClickOnce is built into Visual Studio 2005, is secure, flexible, lightweight (compared to the earlier Microsoft Installer (MSI), etc. deployment technologies), and is capable of interacting with other Microsoft tools. It has a broad reach, too; you can publish Windows Presentation Foundation (.NET 3.0), Windows Forms, or console applications with it.

ClickOnce gives developers a unified metaphor for solving deployment and update problems?not just for the application binaries themselves, but also for all the complex services, controls, data files, static resource files, etc. associated with the application.

All in all, ClickOnce is another attempt to attain one of the “Holy Grails” of software development?providing a centrally-based solution from which developers can deliver applications with all their resources and data files securely to end users and provide a way to keep those applications current.

To accomplish all that, ClickOnce consists of a complex package of technologies containing many features, options, and possible synergies with other Microsoft software tools. This first article has just time and space to cover the basics and one very simple example. However, you should be aware that far more advanced uses of ClickOnce are possible that match the most sophisticated features of the current generation of dedicated installation and update utilities. You’ll have to weigh the investment and mastery of your current tools against the up-front costs of the learning curve for advanced ClickOnce features. And you should be aware that ClickOnce may require you to use other Microsoft tools, such as BootStrapper and Mage.

If you’re already familiar with the process of building MSI files, this MSDN article, “Choosing Between ClickOnce and Windows Installer” provides a useful comparison of ClickOnce with MSI.

Although much of the information about ClickOnce (starting with the name) would lead you to believe that ClickOnce is a completely wizard-driven solution, ClickOnce also has its own advanced API, which you can use to script and customize the install process. If you use it though, be aware that any application code that uses the APIs must have full trust privileges on the clients’ machines/sites. While the ClickOnce runtime itself has full trust privileges, the same may not be true of your application’s install code.

Some Simple Scenarios
From a developer’s point of view, here’s a very simple ClickOnce scenario. You begin with an application created in .NET 2.0, using the built-in publishing mechanism in Visual Studio (VS) 2005 to publish the application to the Internet or to a local server. The VS 2005 publishing process creates metadata files called manifests that control the future installation experience for end users. The publishing process also determines the address you provide to end users that they will use to install the software. Typically, that address would be a URL on a Web server, delivered as the target of a link or submit button in a Web page.

From an end-user’s point of view, installing the application couldn’t be simpler. Users reach the installation via a URL or network share address, both of which end in “publish.htm.” You can provide users with the URL or address via a browser?a link in an HTML page?or simply deliver it as text that end-users can paste into their browser’s address field. Clicking the link or browsing to the address triggers the installation of the application and its resource files.

Once installed, users launch the application using standard Windows styles (for example, via a desktop icon or Start Menu Shortcut). Or they can browse to a provided Web page ending in “.application” automatically generated by the ClickOnce publishing process on the server.

Updating applications is also straightforward. Whenever you, the developer, change your application or its associated resource files, you republish via ClickOnce. Your changed files are automatically re-versioned, and the publishing process creates a new hash for them in the signed manifest. The next time a client launches your application, the ClickOnce run-time built into the .NET Framework (depending on update settings the developer has specified) creates a new folder with the version number as part of the folder name on the client’s machine, then downloads only the changed files into the new version folder.

Sameer Bhangar, a member of the ClickOnce team describes this model of preserving versions as a “side by side app” model, and states that it allows for “robust rollback” and avoids issues that may require a machine reboot. He also states:

“ClickOnce automatically ages out old copies of the app so at most you should have the current and one previous copy of the app in your store,” I have been unable to find a clear statement in MS documentation to this effect. Note that files “marked as data” are handled with a different mechanism and will be re-downloaded, even if they have not changed.”

Some people see the accumulation of multiple versions of the application and resource files on the client’s machine as a problem (note that Visual Studio by default also constructs a similar system of folders on the server when publishing multiple versions of a revised application or its data files).

Deployed applications (depending on settings) behave just like regular Windows applications; they can have a Start Menu entry, a desktop shortcut, a system tray icon, etc.

Obviously, downloading binaries over the Web poses a security hazard; therefore ClickOnce requires a certificate that you use to digitally sign the manifest files in a standard Web-trusted format. Some complex issues surround security certificates, but fortunately Brian Noyes has an excellent blog entry to help you get up to speed on security certificate issues.

ClickOnce Adds Installation Power
If the model I’ve just described sounds similar to current widely used installation technologies such as Microsoft MSI, Wise, InstallShield, etc., you are right on track. But there is much more to ClickOnce than its suitability as an alternative to traditional installers!

For example, ClickOnce easily lets your application check for updates and automatically update every time any user connected to the install source (the Internet or a network server) launches the application. Yes, “update” means that you can use it to plug in changed DLLs or add new DLLs; that you can alter and deploy updated main application .exe code; that you can change resources and data files. And, yes, you can control whether the end users have the option?when updates are available?to cancel their installation or whether your application updates automatically with no end-user cancellation possible.

But there is more…. You can also deploy your application so that the end users can only use it when they are connected to the server or the Internet. In this mode, the application installs with no Start Menu shortcut and no desktop icon?it’s available only via a link to a Web server. I’m planning to use this type of ClickOnce install myself with a real client.

Build A Simple ClickOnce Application
Here’s how to create a simple “real-world” example .NET 2.0 application that will run only when the end user is connected to the Web. End users will see this simple application as just a link to the ClickOnce generated file on my Web site.

First, create a simple .NET 2.0 application in Visual Studio 2005. You’ll need a security certificate with which you can sign the manifests. For this article, I used a free certificate from Ascertia.com.

The Manifests
ClickOnce deployment is controlled by two essential XML files called manifests. One is the application manifest, which has an .exe.manifest file extension. This manifest summarizes the assemblies, required permissions, required libraries, etc. used by the executing application. Each application manifest is specific to one particular version of the application; consequently, each revision of the application caused by republishing from Visual Studio will produce a new application manifest.

The other manifest is the deployment manifest, which contains secure links to the actual files the ClickOnce runtime uses to control the install process (the application manifest and itself). The deployment manifest also contains policy settings that determine the mode in which your application is installed (on-line or off-line), and govern update-mode settings. Unlike the application manifest, there is one and only one deployment manifest per application. A deployment manifest has an .application file extension.

Publishing
The publishing operation creates the required manifests, signs them using your security certificate, and copies the necessary files to the target deployment environment you have selected.

Open the Visual Studio 2005 Project Property Window from the Project menu and choose the last entry, which will have the name of your current project. The Project Property Window has 10 tabs. You use the last three tabs at the bottom on the left side of the window (“Signing,” “Security,” and “Publish”) to set the parameters that control ClickOnce deployment and updating as shown in the following figures.

? Figure 1. Signing Tab: The figure shows that the sample application requires signed manifests, signed (in this case) with the Ascertia certificate as shown.

? Figure 2. The Security Tab: The figure shows the security settings for the sample application.

	?
Figure 3. The Publish Tab: In this tab, set the Publish Location (the default is shown), and specify whether the application should be available offline only, or both on-and-offline.

Figure 1 shows the signing tab for the sample project. You can see that the security certificate from Ascertia.com has been selected?you click the button “Select from Store” to choose it.

Next, look at the Security Tab in Figure 2. There you can see that ClickOnce Security is enabled and that I declared the test application should have full trust.

Finally, you carry out the real business of publishing in the publish tab (see Figure 3). Figure 3 shows the ClickOnce deployment mode set to “Online Only.” For the publish location I accepted the default value publish, which will create a folder inside the folder containing the current project.

I strongly suggest that when you are ready to publish your project, you click the “Publish Wizard” button at this stage and let Visual Studio walk you through the steps of setting (or re-confirming) the publish location, selecting the mode of installation (from a Web site, from a UNC path or Web share, or from CD or DVD), and the location where the application will check for updates.

Note that this simple example didn’t include any resources.

What’s the Downside?
Despite the simplicity apparent from the sample application, early users of ClickOnce sometimes had problems with end-users getting the most recent updates of their files due to Internet Explorer’s caching behavior. A developer I know had to instruct his beta-testers to force a “hard refresh” of IE by pressing Control-F5 to make sure they had the latest files. However, it appears this issue has now been solved by the ClickOnce team.

The same developer found ClickOnce incompatible with the obfuscator he uses (RemoteSoft’s Salamander), and there have been reports of people having problems using the DotFuscator Community Edition software that ships with Visual Studio 2005 with ClickOnce.

Brian Noyes has successfully used ClickOnce with a .NET test application. He first created the application, published it with ClickOnce, then obfuscated the files and updated the manifests using the Mage tool. Using that procedure, he was able to publish the now obfuscated program via ClickOnce successfully.

Some developers found that lack of compression of the files posted to the server by publishing via ClickOnce resulted in heavy traffic when dealing with frequent application updates, because binary files such as DLL’s are not usually highly compressible. But note that MS states that ClickOnce deployment does use HTTP compression if enabled on the server. So, if you’re deploying ClickOnce applications via IIS, be sure to turn on HTTP compression (which will use GZip) on the server. HTTP compression is not enabled by default in IIS 6 but here’s the procedure to enable and disable it.

For one developer the accumulation of different versions of the software on server and clients’ machines during frequent development updates due to the “side by side” model of ClickOnce mentioned above also resulted in file bloat on the clients’ machines. His solution was to switch to using ClickOnce’s publish-to-file-system option, then zip the generated files on his hard-drive, use FTP to put them up on his server where his clients could download them. You may wish to evaluate if using ClickOnce in a very frequent update situation, like beta-testing, is a good strategic choice.

While not everyone will run across the problems described so far, there is one generic problem that everyone may encounter, related to security certificates. If your certificate expires and you renew, ClickOnce subsequently treats your revised application as an entirely new deployment, possibly leaving your previous version physically present on the end-user’s machines. Your end-users do need to uninstall and then re-install the entire application. This forum is a good source for other problems being reported from the field about ClickOnce and acknowledged by Microsoft.

Final Thoughts
At this time, I believe that ClickOnce is a fantastic “free” solution for the .NET 2.0 developer who wants to deliver simple classic desktop executables to end users via the Web?and keep the application updated. It offers many interesting and compelling features out-of-the-box without having to mess around with other software tools.

I find it impressive that you can create ClickOnce installs that run from a hard drive, a Web server, an FTP site, or a CD! I’m planning to use it myself in its “must-be-online” mode to try and sell a client a prototype piece of software. If they don’t buy my prototype, I’ll pull the files off the server?and the application’s gone.

If you are a small software house publishing an application with complex and frequently changing resource and data files, I believe ClickOnce is definitely something you should look into on a cost-benefit basis. Compare what ClickOnce offers to your current tools and their costs. You may find ClickOnce a valuable replacement for your existing deployment, install, update model.

If you are a network administrator with a lot of machines running mission-critical applications, many users requiring different downloads based on their security level and zones, tight needs for security and access control, and have a substantial investment in third-party tools used for updating, I think, at this point, you should at least explore ClickOnce, keeping it on your radar while following its evolution.

If your company has a deep mastery of Microsoft’s MSI technology and of tools such as Mage and BootStrapper, then I think ClickOnce should be an immediate priority target in your ongoing search to improve the efficiency of the development and deployment aspects of your business.

If you have a heavy investment in COM components carried into your .NET apps (may the Gods help you !), and you want to use ClickOnce, you are also going to have to use “Registry Free COM” deployment (which should already be on your radar).

Finally, bear in mind that ClickOnce is merely a step along the progression from manual local installs to seamless automatic remote installation and update, but the evolution isn’t over, as you can see by the problems listed in this article, and some of the information you can glean from the Helpful Links sidebar. You should expect to see future innovation in deployment, installation, and update technologies.