ClickOnce
After looking into ClickOnce for Pogo’s deployment needs I came away quickly with some obvious flaws in it’s design.
ClickOnce seems to be designed to allow corporate IT departments to easily deploy simple in house tools to people who need them, while ensuring that when an update is released the user base is quickly and easily updated. This case works rather well given that the target users all use Windows as their desktop environment1. For web deployments which is ClickOnce’s intended audience there are significant issues that ultimately is going to force me to go to another install system.“Bring the best of web application deployment to client apps. Easy of deployment should no longer be a reason customers must build web apps instead of client apps.”
—ClickOnce Team Blog
This all falls down when you give thought as to why people create web applications rather then native applications. The combination of remote accessibility, security capabilities, cross-platform compatibility (Windows, Linux, OS/2 Warp, you’re old Amiga), and instant deployment of changes. Of course the serious downside to these benefits is reduced performance and very cumbersome user experience.
ClickOnce attempts provide a install method that is as simple as loading a web page but this desire comes from a somewhat misguided understanding of why people deploy web-applications.
Then compounding this lack of understanding is the lack of cross platform compatibility. If you write you application in C# for Windows you don’t expect it to magically work, but the install process you expect to function just fine on the intended platform. This is where ClickOnce falls on it’s face. The only way to install from a website is to use Internet Explorer. Firefox, Opera, and Safari have no way of recognizing the ClickOnce install method and providing user a coherent experience. Since the install process boils down to downloading a bootstrap program called setup.exe which then calls back to the website to inquire about the application manifest, this process could easily be handled in setup.exe rather then forcing a custom mime type handler in IE to be used.
In theory there will be proper documentation on how to handle this at some point from Microsoft2, so in theory someone will write plug-in’s for various browsers, and in theory the end-user will magically know to install these plug-in’s then go do the installation. At this point you might as well use a different installer so you don’t loose ~30% or more(Technology sites generally have a wider distribution of browsers in use.) of your potential users because they won’t be able to easily install your application.
Looks like I’m going to package Pogo in NSIS and be done with it.
Summary
The Good
- Easy to configure (for C#)
- Already integrated in Visual Studio 2005
- Easy to deploy – Simply upload a group of files to a webserver
The Bad
- Requires IE to run installation2
- Clients with Linux and Mono can’t install
Links
Footnotes
1 Not uncommon in companies where there is a standardized desktop environment. People serious about this though tend to already have a central domain system where they can remotely push installations.