A Brief Introduction to ClickOnce

ClickOnce (a new runtime feature in Whidbey) is designed to solve many of the traditional problems associated with the deployment and maintenance of a .NET client application. It takes away much of the traditional pain of generating installer files and handling different security zones.

How do you use ClickOnce? Well, when you’ve created your application, you can run the Publish Wizard, which is the primary interface into ClickOnce. The selections you make here determine whether the application is available whilst connected to the network only or also offline, what security settings are required, if a public/private key pair is to be used for signing, and a location for publishing. Visual Studio then publishes the solution to the chosen location including all the shortcuts and configuration files required. By default, applications are set to run in a sandboxed environment (probably the intranet zone, if you’ve picked a local URL) However, if your application does something unsafe (such as file I/O), then on executing the shortcut it will prompt for permission to grant elevated permissions.

As part of the ClickOnce process, you can choose which prerequisites are necessary (e.g. MDAC, .NET Framework 2.0). When you execute an application, ClickOnce can check for updates: either before the application starts or in the background as the application is running. You can even configure a different update location from the original source and set whether accepting the update is mandatory or not. All these settings are available from a new Publish tab from the project properties.

ClickOnce is not a panacea for all solutions, for example, if you wanted to install a shell extension or install a component into the GAC, you’d need to create a full MSI project (also supported by Visual Studio). But for a “typical” departmental application that is to be deployed via the intranet, it’s a great solution.

Comments (3)

  1. Luc Cluitmans says:

    I may misunderstand some of the functionality of ClickOnce, but my initial reaction is somewhat negative – please correct me if I misunderstood something.

    Hmm, doesn’t this technology go straight against everything we learned from how viruses and worms spread? I can imagine it is a decent technology for (trusted) intranet use, but people will want to use it on the internet.

    I can see already how ClickOnce-based trojans will work: first the user downloads some ‘nice spiffy program’ that seems harmless and is harmless. Then, suddenly there is an ‘update’ to the nice tool, which installs a zombie client, without the user realizing it. And a dialog showing ‘do you want to give this application BlaBlaBla permissions?’ is not going to help, the user is only interested on finding the button that makes his application work again.

    From this description I will most definitely avoid ClickOnce like the plague… The fact that it will work great for IntraNet use doesn’t prevent getting ClickOnce a bad name based purely on its internet issues.

    And probably people will link it to the ‘huge success’ (not!) of Sun’s Java WebStart – at least to me it sounds like a similar technology.

  2. Mehran Nikoo says:


    User’s consent is the key here, if the user doesn’t trust the source (either by looking at the URL or using the public/private key pair) then he or she shouldn’t have said "Yes" to the confirmation dialog box in the first place. This is same as saying what happens if Microsoft publishes an update, which is a virus!

    ClickOnce is not promising a way of being able to install any applications with a single click and also guarantee that no single person in the world has a bad intension. It is mainly targetted at local intranets, and if you are running/installing over the Internet, then traditional rules still apply (e.g. don’t download if you don’t trust the source / use other means e.g. SSL and Private/Public keys).

  3. Tim Sneath says:

    I dropped a line to Shawn Burke, who’s a dev manager in the rich client team and he kindly mailed back several points of clarification (along with highlighting a few misconceptions in my original post, which I’ve now corrected). Rather than paraphrase, I’ve posted his comments intact. Hopefully this answers some of your concerns, Luc…

    – ClickOnce isn’t a designer feature, it’s a .NET Runtime feature that will also be baked into Longhorn

    – ClickOnce allows deployment and maintenance of client applicaitons with the ease and maintainabliity traditionally associated with web applications

    – ClickOnce allows you to define an application and include any set of bits in that definition (dependancies, resources, etc)

    – ClickOnce does not generate an MSI — it is a completely different technology

    – ClickOnce applications installs are per-user only, and by default can not affect machine state by pushing things into the GAC, changing registry settings, etc.

    – ClickOnce can be used to roll out dependencies including the Framework itself, as well as things like MDAC etc. Of course, you need to have install permissions on the client machine for these types of things, but for the managed apps themselves, they are no-impact.

    – ClickOnce does allow a user to grant the application permissions that are higher than the default partial-trust sandbox operations. Unfortunately, for organizations that don’t have the facilities to roll out policy, you can’t do what you need to in partial trust. A mechanism for permission elevation was a major request from a large number of customers using HTTP-based deployment in v1.x.

    WRT to the spoofing scenario the gentlemen speaks to on your blog, the spoofer would need to have control of not only the server the application came from, but the keys with which it was orignally signed (all clickonce apps are signed with strong names for exactly this reason). You can’t insert yourself in the middle and cause an application to update when it shouldn’t. Security has definitely been a major priority with this technology.