views:

1021

answers:

4

I am writing an application that needs to be installed on a large number of desktops and also needs to update itself. We are looking at WIX for creating the installation. I have used ClickOnce and it is not a good solution for this install. WIX seems to fit, but there is no good process for auto update that I have found.

I have looked at ClickThrough, but it doesn't seem ready for prime time yet. Does anyone have another good solution to use with WIX (or maybe another install program) to auto update an application install?

+1  A: 

Just how "auto"-update does it have to be? :-)

We use WiX (2.0) for an app that needs to be installed over and over again. As long as you go with "major upgrades" from version to version, that works just fine - you can uninstall the old version and then re-install the new one - no major problems here.

The key is to have a stable "UpgradeCode" (a GUID in your WiX) that never changes - it's the key for your app - and to have a new ProductCode for every release.

Then, in your wxs file, you need two bits:

<Upgrade Id='--your-updatecode-GUID-here--'>
    <UpgradeVersion MigrateFeatures='yes' RemoveFeatures='ALL' />
</Upgrade>

<InstallExecuteSequence>
  <RemoveExistingProducts After='InstallInitialize' />
</InstallExecuteSequence>

That should do it!

Other than that - nothing really much to say - it just works :-)

Marc

marc_s
thanks for the response... I am looking for something that can get and install the update over the network automatically.
Brian ONeil
+1  A: 

Windows Installer isn't really designed for "self updating" software. If you don't need MSI, or really need the application to "pull" it's own updates then use NSIS or some other tool and write your own updating routine/service.

However if this is being installed on a large number of desktops within a single organisation, then the better solution would be to deploy an MSI via Active Directory. You can then "push" out updates using Group Policy. This is going to be much more robust than any application that updates itself.

sascha
Active directory is not really an option for me. I will read up on NSIS and see if it will fit my needs. Thanks for your answer.
Brian ONeil
+1  A: 

Yeah, ClickThrough really is what you're looking for here. There are bits and pieces in it that work. You might be able to dissect the code and use it yourself without all the extra "UI + build integration". Most of the bugs are in the higher levels. At the root, the RSS update and executable bootstrapper work fine.

Rob Mensching
okay, I will give it a try and see how it is... I have just read that it still needed work to be ready. If I can get the major pieces out of it then that might work.
Brian ONeil
+1  A: 

Let me start by saying we offer a complete updating solution which includes:

wyUpdate handles all of the Vista/Windows 7 UAC problems and all the file permission problems that inevitably pop up when you're trying to update complex software.

That being said, if you want to build your own updater here are some tips:

Building your own updater

A good place to start is the wyUpdate C# source code I mentioned above. You can cannibalize it and use it for your own purposes. Some of the algorithms it contains:

  • Full Windows Vista / Windows 7 UAC support
  • Ability for limited users to check and then update if they have credentials
  • Support for wonky corporate inernet. (If you've ever worked with a corporation this is a real problem).
  • Quick extracting, patching, and installing of files.
  • Registry support.
  • Roll back files & registry on error or cancellation by the user
  • Self-update (no files left behind)

We also have the file specifications here.

Automatic updating

Since being automatic is a requirement let me tell you how we do it with our AutomaticUpdater control.

We use named pipes to communicate between the standalone updater (wyUpdate) and the Automatic Updater control sitting on your program's form. wyUpdate reports progress to the Automatic Updater, and the Automatic Updater can tell wyUpdate to cancel progress, to start downloading, start extracting, etc.

This keeps the updater separate from your application.

In fact, the exact named pipes C# code we use is included in an article I wrote a little while back: Multi-process C# app like Google Chrome.

Wyatt O'Day