Skip to content
November 6, 2007 / Bob Black

Automagical Update

I’m becoming more and more convinced that the best application installer out there is WiX. No, it doesn’t have a fancy GUI, and yes, it has a crazy nasty learning curve, but once you get into it’s innards it is awesomely powerful.

I’m doing some work on the next minor version of Code Toaster, which (hopefully) will include an automatic update feature. After reading (again, for the ka-jillionth time) this tutorial on creating an update msi with WiX, methinks it should be fairly straightforward. The process will go something like this:

  1. When Code Toaster launches, it will download an XML file containing version information.
  2. If there is a new version (as noted in the XML file) Code Toaster will download the msi installer for that update.
  3. Code Toaster will launch the msi and exit.

One problem I’ll have to resolve is how to install an update while Code Toaster is running. The most oft-used and recommended solution for doing auto-updates is to launch your application via a proxy that does the update work, and then launches the application later if no updates are available (or after the update process is complete). But I don’t like that for a couple of reasons. 

  1. If there are two executables, CodeToasterProxy.exe and CodeToaster.exe (or whatever), that might confuse a user as to which one to run (users would run CodeToasterProxy to get the update capabilities, not CodeToaster.exe).
  2. Since CodeToaster.exe can be run as a command-line application (to compile/run templates in batch mode, for example), it should be intuitive which exe to run in that scenario. In this case, the user would run CodeToaster.exe, not CodeToasterProxy.exe.

I bet you’re looking at this post cross-eyed after that wonderful explanation, huh? Maybe I should have boiled it down into one reason: confusion. And we sure don’t want Code Toaster to be confusing.

There is another option : to have Code Toaster check for and download updates, and then launch a separate application to run the msi update. That would keep things intuitive – you would always launch CodeToaster.exe rather from the command-line or from the Windows GUI, and CodeToaster.exe would remain in control of the update process. The only problem, and a minor one at that, would be the installer app would need to wait until the Code Toaster process had successfully exited before beginning the install. So step-by-step, it would work like this…

  1. CodeToaster.exe launches and downloads an XML file containing information about available updates.
  2. If an update is available, CodeToaster.exe asks the user if they want to go ahead and download and install the update.
  3. If the user wants to install the update, CodeToaster.exe initiates the download.
  4. Once the download is complete, CodeToaster.exe launches the installer application, and then exits.
  5. At this point the installer must wait until CodeToaster.exe has finished exiting, and then launch the update .msi file that was downloaded earlier by CodeToaster.exe.
  6. Once the msiexec process has exited, the installer app can re-launch (the now updated and bodacious than ever) CodeToaster.exe, and way the user goes!

Whudya think? I think I like it. That’s the route I will probably take – there are a lot of steps but I think it’s more elegant than having a proxy app between the user and your application. Howsomever, there may be someone out there who knows better – if so let me know.

On another note, I’ve noticed that Windows Installer packages are quite difficult to update. You can’t just run an msi containing a minor (version) update, because you’ll get an error message that says “Another version of this product is already installed.”

Well, duh! I want to update the version that is already installed!!

So you have to run your msi using the following command:

msiexec /i MsiFileName.msi REINSTALL=ALL REINSTALLMODE=vomus

Don’t ask what “vomus” stands for. I couldn’t find an adequate definition/explanation on Google within my 5-second attention span. But this is another reason to use an automatic update design instead of asking the user to run an update msi manually. Ask a user to do that to update your software and they’ll hate your guts and call you names.

This, too, is documented in the WiX tutorial, lesson 4, if you’re interested in some late night fireside reading while your hunting dog naps beside your overstuffed armchair.

So, looks like I have some work to do.

Onward.

Advertisements

5 Comments

Leave a Comment
  1. Chris B / Mar 11 2008 11:22 am

    Have you tried using DARK to generate WXS from a webapp MSI? The resulting WXS can be built into an MSI, but when you run it, during the install progress it fails. I can’t for the life of me figure this one out.

  2. Bob / Mar 11 2008 2:02 pm

    Nope, I haven’t had the need to take an existing msi and build a new msi. I’ve been building the WXS files for Code Toaster by hand.

    You might try turning on msi tracing, which creates a log file that might show where the problem is. Here’s an example: http://www.dalun.com/wix/06.15.2005.htm

  3. ewart / Mar 20 2008 1:54 am

    Did you suceed? I’m are almost there, my app automatically checks versions, downloads the new version, and launches the new MSI installer directly (then exits). The installer runs and upgrades the version. Only problem I have now is that my app is NOT automatically re-launched after the installation of the newer version — did you figure this out??

    When it installs for the *first* time, it will correctly launch my app, but not when I install the upgrade:

    NOT Installed

    also, I was a bit confused in your comments as to whether you are using a third executable or not to control the installation process. I’m not – just launching the MSI directly from the old version of my app.

    I hear you on your MS comment – I’m doing exactly the same thing for my app installation and frankly it feels like I’ve wasted many frustratting hours to make this work, it’s like the whole installation process was an afterthough.

    regards
    ewart

    ps I re-download the whole app+installer again as getting patching working with WIX is a (*($*# nightmare, gave up wasting time on it in the end.

  4. Bob / Mar 20 2008 6:26 pm

    I’ve temporarily shelved my work on the msi installer while I work on more pressing issues, like bugs with Code Toaster itself, so at this point this is still a work in progress. My original plan was to use a second application to launch the msi to avoid any conflicts with locked files and so forth. Since it sounds like you have it working without a separate launcher app, I may give that a try (just launching the msi from my app’s exe) and see what happens.

    Good comment – thanks!

  5. Anonymous / Jul 15 2011 1:13 pm

    VOMUS =

    v Use to run from the source package and re-cache the local package. Do not use the v reinstall option code for the first installation of an application or feature.

    o Reinstall if the file is missing or is an older version.

    m Rewrite all required registry entries from the Registry Table that go to the HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT

    u Rewrite all required registry entries from the Registry Table that go to the HKEY_CURRENT_USER or HKEY_USERS

    s Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and icons.

    http://msdn.microsoft.com/en-us/library/aa371182.aspx

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: