1

I'm trying to automate an install process in which I uninstall a previous version and install a newer version over the top. How should I test (in my bootstrapper, coded in C#) if the uninstall was a success?

This is currently how I'm launching the uninstall.

Process p = Process.Start("msiexec", /*various switches*/);
p.WaitForExit();

I'm also currently tangling with dynamic multiple instances, which really bend my mind, so handling this problem within WiX itself is difficult if not impossible.

Izzy
  • 1,764
  • 1
  • 17
  • 31
  • @Soner Gönül: There are multiple ways for me to solve this problem, I could set a registry key called "uninstall success" and then set it to true as a custom action on uninstall -- however this is incredibly dirty. If you have any good practices or good ideas I'd like to hear it before I commit. – Izzy Jun 17 '13 at 14:21
  • You should mirror your previous versions installer by checking for the existance of Files, Directories, Registry keys, etc... – Dustin Kingen Jun 17 '13 at 14:21
  • @Romoku There's no guarantee that any file or folder I check for will still exist anyway later in the life of the product. – Izzy Jun 17 '13 at 14:23
  • Well you can either keep a catalog of information for each version that you can use to verify application integrity or create some kind of update program to manage install/uninstall and just assume if it doesn't exist then the machine is clean. – Dustin Kingen Jun 17 '13 at 14:27
  • @Romoku They're still quite dirty fixes, I'd let WiX handle updating if the code structure allowed it. – Izzy Jun 17 '13 at 14:34

2 Answers2

2

As an alternative to handling this in your bootstrapper, and assuming that the installer for the newer version is a Windows Installer package (.msi) under development, you can use Windows Installer functionality to uninstall the older version, where required. When you do that an upgrade can be one of the following:

A major upgrade is basically the removal of the older version and installation of the newer version. WiX allows you to author any of these in a setup project quite easily.

So, your bootstrapper would just need to install the newer version and let Windows Installer do the rest.

BTW—You might want to look at using a WiX Bootstrapper instead of writing your own logic. If you wish, you can write a custom UI in .NET for a WiX Bootstrapper, if that's the reason you're writing your own bootstrapper.

Tom Blodget
  • 20,260
  • 3
  • 39
  • 72
  • I'm tangling with some hilarious dynamic multiple instancing and I couldn't find a way to provide an upgradecode so this would work without affecting other instances. Sorry, I probably should have tagged this.. – Izzy Jun 18 '13 at 07:41
2

Rather than invoke Windows Installer through msiexec, you can use the Windows Installer API. You can do that through P/Invoke, activating the COM interface or via WiX's DTF wrapper library. The specific function to use to remove a product is MsiConfigureProductEx.

With DTF, you can do it like this:

Installer.SetInternalUI(InstallUIOptions.Silent);
Installer.SetExternalUI(UiHandler, InstallLogModes.Verbose);
Installer.EnableLog(InstallLogModes.None, null);
Installer.ConfigureProduct(productCode, 0, InstallState.Removed, "");
Console.WriteLine("RebootRequired: {0}   RebootInitiated: {1}", Installer.RebootRequired, Installer.RebootInitiated);

The UiHandler delegate allows the app to monitor progress. If there is an error, DTF throws an exception.

Tom Blodget
  • 20,260
  • 3
  • 39
  • 72