IT:AD:ClickOnce
Summary
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.
Notes
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 noEntryAssembly
, 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.
Resources
- Good Tutorial: