Are auto-updating applications really that useful?

Being incessantly nagged gently reminded by over a dozen applications (and some of their plug-ins) in the past week that there’s updates available, I really have to question whether all these auto-updating (or even just auto-checking for updates) applications are actually worth the hassle.  Sure, when you’re developing an application you’re thinking “My users are never going to bother checking for bug fixes on their own, we’ll have the application call home and check for updates itself.”  That’s all well and good until you realize that you are not the only one in the world developing an application and you’re not the only developer with that thought.  When a single application notifies you that it can be updated, that’s no big deal.  When you have a dozen of them over the course of a week that need to be updated, that becomes a major pain.  Especially for those users that still have UAC turned on.  Granted I seem to be in the very obscure minority of users who keep UAC on, it’s still an unnecessary step to require admin rights, even when the installer itself is never writing to a protected file/folder/registry setting/etc. that really should never require admin rights.

I think the biggest issue with installers seem to be that those that install the application in the Add/Remove Programs Programs and Features are actually creating a registry value in HKEY_LOCAL_MACHINE.  If only a purely user-based installer existed.  Or better yet, Programs and Features listed user-based installs as well as machine-based installs.  I think ClickOnce can support user-based installs, but not everybody wants to use ClickOnce.  Not even in the .NET environment where it’s part of the toolset.  Most teams seem to turn to easily scriptable options like NSIS or WiX.  In all honesty I haven’t looked at ClickOnce since it first came out with .NET 2.0/VS2005.  I could only find one situation where it actually fit my needs, but outside of that I constantly hit limitations and pain points with it.  Perhaps those have been fixed by now, but I haven’t had a need to write an installer in recent projects.  Outside of the .NET world (especially in open source applications that build installers), NSIS seems to be pretty common.  Ed. Note: usage of tools is purely subjective conjecture based on looking over code bases, noticing the standard UI rendered by the tools, and some the fingerprinting the tools leave out the installer artifacts.  I may be missing other common installer creators (InstallShield is out there, but is quite expensive) or grouping them together incorrectly.  A problem with this is that different installer types are created.  MSI’s are recognized as installers and thus require admin rights in order to run them.  NSIS outputs executable installers.  Depending at the flags in the script, the admin rights prompt may not occur until it first tries to write to a protected area.  I’ve also seen this hang up the installer or cause it to outright cancel the install.  Talk about a bad user experience.

I’m not really sure what point I’m looking to make with this post, but it’s a rant I wanted to get off my mind.