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.

Advantages: * 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)

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

Disadvantages: * 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).

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.