Adventures In Installing

A pretty common feature in applications is the ability to automatically update when a new version is available.  Of course many designs have been created to address this, from having pre-launchers, to ClickOnce, to web services, to notifications, and on and on.  There’s plenty of ways to solve the problem, each with its own set of benefits and drawbacks.

The design I recently faced was one where the app would launch, check the database for a new version and if one existed, would display a notification, launch the installer and exit the application.  A couple of things were less than ideal with this.  First, the installer would be the standard interactive install, so you got used to hitting Enter 3 times to jump through the screens.  Second, after install, you’d need to relaunch the application.  So I decided to try and resolve these issues.

The first step I thought would be easy.  I would launch the install using MSIEXEC and use the /QR to make the install non-interactive.  This seemed really nice until a bug surfaced where the /QR switch would not perform an uninstall of the previous version, resulting in multiple entries in the Add/Remove Programs list.  This bug was reported back in 2010 and with VS 2012 coming out, I guess it will never be resolved.  With a lot of trial and error, since there seems to be no workaround for the problem on the Internet, I found that the /PASSIVE switch will uninstall the old version, so that was my new plan.  However, with /PASSIVE, there is no notification the install is complete.  That’s fine for now, because I was going to make the app relaunch after completion.

After a lot of study on custom actions, I got the application to launch after the install.  Now I have a problem where the application is being launched as SYSTEM instead of the current user.  This would make the database access fail.  More trial and error, because there doesn’t seem to be any info on this issue either, and I found that when you choose the InstallAllUsers=true option, MSIEXEC runs as SYSTEM, which makes sense since it would need access to write to the All Users sections.  But if you set InstallAllUsers=false, then MSIEXEC runs as the current user, which then would launch the application as the current user and all would be well.  That is, if you’re willing to give up the All Users install.