Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 8

ClickOnce: Delivering .

NET Applications Via the Net


With ClickOnce, Microsoft delivers a client-side application deployment and updating solution that offers
a glimpse into the future, where centrally-located and managed applications delivered via the Web don't
have to run in interface-challenged browsers.

Introduction
From 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.

Author's Note: At the time of this writing, neither RemoteSoft nor PreEmptive had
responded to my technical queries about using their obfuscators with ClickOnce.
Please see the sidebar "ClickOnce Open Issues" for a brief interview with Adriaan
Canter, Microsoft's Dev Lead for ClickOnce, and for more discussion of obfuscation
issues.

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.

You might also like