ClickOnce was the quick and dirty WinForm/WPF deployment solution that they rolled out with .NET35.

It had a few neat features but never enough to compete against:

  • it's limitations
  • the fact that WPF was too little too late, when the world was moving towards the browser.


  • It's a lighter solution than having to use InstallShield and MSI.
  • Does the basics of adding some shortcuts.
  • Support for automatically downloading updates from the Web.
    • For all its limitations compared to an MSI (IT:AD:WiX) packaging solution, this is probably its main point of interest.
    • Apps can be configured to check on demand or automatically (periodically).
    • note that when users launch our application, they actually run a shim that checks for newer versions and offers to download them, and start the new app.
  • Support for installing and running applications in limited trust scenarios.
    • this feature is available only if we create a XAML browser application (XBAP)


  • It hasn't really taken off. The only significant effective use of it I've seen is (funny enough) Google Chrome's installer.


  • Tightly tied to the concept of AppDomain/EntryAssembly.
    • IT:AD:PCL does not have AppDomain, therefore no EntryAssembly, so code built around ClickFirst is not easily reusable.
  • References the System.Windows.Forms assembly to get the Company/App/Version specific directory of Roaming/Local application data directories
  • ClickOnce apps can run in IE browsers.
    • That's not an advantage: it gives Management a false sense of reuse, when in fact this ties down users to not switch to their browsers of choice.
  • Tightly integrated to the concept of WPF – which is basically dead in the era of HTML5 (if your company is still churning them out thinking there's a future in them, consider changing jobs).
  • Installed for a single user (can't be done for all users on a workstation).
  • Very limited compared to an MSI installer (see IT:AD:WiX).
    • ClickOnce does the basics of adding some shortcuts – but if you need anything at all that is more complex – including finer grain control over shortcuts, registry, database connections, you will need a more powerful installer generation tool.
  • ClickOnce applications are always installed in a system-managed user-specific folder.
    • We cannot change or influence the folder where the application is installed
  • If ClickOnce applications are installed in the Start menu, they show up as a single shortcut in the form [Publisher Name] ➤ [Product Name].
    • We can't change this, and we can't add other shortcuts, such as a shortcut for a help file, related website, or an uninstall feature.
    • Similarly, we can't add a ClickOnce application to the Startup group, the Favorites menu, and so on.
  • We can't change the user interface of the setup wizard. That means we can't add new dialog boxes, change the wording of existing ones, and so on.
  • We can't change the installation page that ClickOnce applications generate.
    • However, we can edit the HTML by hand after it's generated.
  • A ClickOnce setup can't install shared components in the global assembly cache (GAC).
    • Although this practice is now frowned upon, so that's actually a good thing.
  • A ClickOnce setup can't perform custom actions (such as creating a database, registering file types, or configuring registry settings).

When to Use Click Once

Frankly, MSI (see IT:AD:WiX) offers many better features than clickonce, so it's hard to recommend using ClickOnce.

ClickOnce is potentially useful for the following scenarios:

  • Intranet deployment of LOB WPF applications
    • But first consider building a Web App instead over restful services. Or consider choosing a web plugin for an existing web portal.
  • ClickOnce may also make sense for consumer applications that are deployed over the Web, particularly if these applications are updated frequently and don't have extensive installation requirements.
    • Maybe. But there will be other (ie, non-free) solutions that are better.