I’ve had a fair amount of experience with Windows-based installers in the past, including non-Microsoft Installer based systems like NSIS and the open source WiX, but most of the time I’d been working with one-off installers for native code projects, like the Ogre3D SDKs. I pride myself in not pre-judging the best toolset to use for any given problem – which is why I switch languages a lot – so when I came to write SourceTree for Windows, which is based on .Net, I checked out the landscape again.
I discovered that ClickOnce was Microsoft’s recommended approach to .Net application deployment , and had the advantage of including both the installer tech and an auto-update system, together with Visual Studio integration, a simple deployment model and so on. I’d seen it used on a couple of other products, and during testing both internally and with our batch of beta testers all seemed to be well, so that’s what we went with for the release.
Hindsight is a wonderful thing, and it turns out that ClickOnce has a number of problems which only really show up when you use it at scale, by which time it’s a bit too late and you can find yourself with a lot of support requests. Here are some of the issues:
- No support for proxy servers
It turns out that ClickOnce just doesn’t work at all with secure proxy servers which can’t authenticate automatically. It also turns out that a lot of people have this kind of setup. There’s a (nasty) workaround for the auto-update system, but this can’t work for the first install. Microsoft have known about this problem for some years, but have decided not to bother fixing it. - Packaging format is just a folder of many files
ClickOnce puts all of its files in a folder per version and just tacks ‘.deploy’ onto the end of each. Simple, but it has many problems:- Some corporate firewalls will detect that some of those files are executable binaries, and will flag them as dangerous. Some will totally block the file making the install/update fail with a download error, some will ‘sanitise’ the file and send that on, making the install fail later with an ambiguous hash mismatch error.
- If you use a CDN to distribute your installers, distribution of many files is very difficult to make atomic, potentially leading to temporarily incomplete results being visible
- Having the download (first install and update) as a multi-file affair makes failures due to interrupted connections etc much more problematic, vs just resuming the download of a single package.
- You can’t separate the update metadata from the update itself
That is to say, ClickOnce forces you to use a single URL for both the metadata where it finds that there is an update, and where it gets the actual update from (the installation files are in a subfolder). This might seem sensible, but in practice it’s very limiting. If they’re separate, you can point the metadata URL at a location which you can update in-place and which will never change, and you can put the update files themselves wherever you like (a CDN usually). ClickOnce forces you to put both in the same URL, which is limiting when it comes to reorganisation, and also it can mean you have to put the metadata on the CDN too, and CDNs don’t often like files that update in-place. It’s just an awkward and inflexible system. - Random weird sh*t in a small percentage of cases
We’ve found over the last couple of months that occasionally a user’s machine refuses to install or update despite the ClickOnce installer being fine for everyone else, and in circumstances that were not explainable by the other issues listed above. It’s not that common, but even if it’s only 0.5% of cases the numbers were starting to add up. We often managed to work around the problems manually, but it’s just not something you want to spend your or your customer’s time on. - Other niggling limitations customers don’t like
None of these are deal-breakers in their own right, but combined with everything else they’re worth mentioning:- You can’t choose where to install the product – ClickOnce chooses an esoteric location for you
- ClickOnce’s reliance on the logged in user means you can’t install once for everyone on a PC, or distribute a bulk install as admin
- No offline installer – while you can zip up the deployment it didn’t work for everyone
So, all these things have been building up , tempered with workarounds but nevertheless a constant thorn in our side. In the end, we had to make the call that ClickOnce just wasn’t salvageable as a deployment tech to use at scale. Instead we’ve moved to a standard Microsoft Installer based tech stack, using Advanced Installer to build the installer and the update system. I really liked Advanced Installer because not only does it address all the issues above, it saved me a ton of time over building something myself with WiX (and having to solve the prerequisites bootstrapper and auto-update system), and was also just complex enough to do what I needed; it’s a pro tool but doesn’t require 3 months training to master it, you can pick it all up in a few days.
I wrote this blog post because it’s what I wish I’d been able to read before I decided to use ClickOnce. It’s one of those technologies that looks fine on the surface and in limited testing but then reveals a bunch of horrid edge cases and random unreliability issues in the wild, just when you don’t need it.
It’s seems you can’t tune into any sort of political debate on the economy these days without a glut of commentators and politicians lining up to tell us how all our problems can, nay must, be solved by ‘attracting investors’. We must do everything we can, we’re told, to catch the eye of these incredibly elusive and rare beasts, who are constantly on the move and always on the lookout for the juiciest pickings. They’re a different breed from us if you’re to believe the breathless accounts of expert observers; by all reports globally mobile, notoriously fickle and with the patience of a three year old after three tubes of blue Smarties. Miss your chance by making things hard for them – common faux pas by the poorly prepared include having labour laws and asking them to pay some tax – and they’ll breeze past your metaphorical begging bowl and on to more attractive opportunities. The only answer is to prostrate yourself at the feet of the investment cadre, regardless of whether you have to slash other things like health and education to do so, because if you don’t your destiny is destitution anyway. Or so the narrative goes, admittedly dressed in slightly more palatable phrasing. You’re not supposed to question this, it’s part of the doctrine of the 
One of the things I hear on occasion is the maxim ‘People buy from people’. Usually what people mean when they say this is that the only real way to sell things to people is to go meet them, shake their hands, wine and dine them, play golf with them, organise trade delegations to impress them, and so on. I’m sure that’s still the way it works in some industries, especially those which are large, slow-moving and headed mainly by the over-50s who are most comfortable negotiating over walnut boardroom tables. I hear sometimes what cuff-links or school tie you wear is somehow a relevant factor in the negotiation. Curious.

Home