1

I've delivered version 1.0 of my software with a WiX-generated installer, and now I want to deliver/disseminate version 1.1. If possible I would like to avoid the situation of telling people to remove 1.0 manually first before installing 1.1.

However, I've had to modify the InstallScope, changing it from perUser to perMachine for various technical reasons. Not a big deal, except it makes upgrading a hassle.

What I'm seeing happen is the same thing that this post mentions, wherein even though you've done all the proper work to implement an upgrade, when it's done you see two different entries on the list of installed programs, one is 1.0 and the other is 1.1. And this is causing problems in the software.

So it would appear that the basic "remove the previous version" logic doesn't work here, so I need some other method of having the previous version uninstalled. I tried to go down the path of firing off the proper msiexec /x command remove the previous version via a ShellExecute CustomAction, but unless I'm missing something there's no place in the sequence where this would work because you're firing off one msiexec command in the middle of another running.

Then I stumbled across this page which details a little-documented method of "chaining" MSI's together:

setupbld.exe -out $(TargetDir)setup.exe -msu FirstInstaller.msi -msu SecondInstaller.msi -setup $(ProjectDir)setup.exe

Sounds great - all I need now is some MSI whose sole function is to remove version 1.0 and then I can chain that together with the old one.

Except I'm not finding a lot of documentation on how you could do that. In fact, since this could in theory potentially be used to remove software you didn't originally install, I'm not sure this is even technically possible for security reasons.

Does anyone know how to create a MSI using WiX whose sole purpose is to uninstall the software? Or am I attacking this problem completely wrong?

Community
  • 1
  • 1
Tom Kidd
  • 12,830
  • 19
  • 89
  • 128

2 Answers2

2

Use this Wix to uninstall the previous version as part of your 1.1 version. I'm not sure why you need to chain the MSIs together.

How to implement WiX installer upgrade?

EDIT: I missed the change in InstallScope requirement. So what is really needed is a bootstrapper.

I posted how to create a BootStrapper here: I need a WIX Bootstrapper Project that installs MY software and prerequisites

Community
  • 1
  • 1
DarrellNorton
  • 3,901
  • 2
  • 21
  • 21
  • While this is usually good advice, the change in InstallScope prevents Upgrade table entries from uninstalling the previous version, as stated at the beginning of Schnapple's question. – Michael Urman Dec 08 '10 at 01:43
  • I'm not sure why I missed that part of the question. Doh! – DarrellNorton Dec 08 '10 at 12:02
  • Something I forgot to mention is that the software involved in my post is not .NET-related (i.e., it doesn't use or need .NET), so I can't require that .NET be a prerequisite for running the installer (a pre-1.0 incarnation of this software did need .NET and boy howdy did we find out how many XP users didn't have it installed). At a glance I can't tell - does the DotNetBootstrapper project referred to in your linked question require .NET to run the installer? Or just .NET to run the GUI to design it? – Tom Kidd Dec 08 '10 at 14:45
  • It just uses .NET to run the GUI to design it. All it ends up making is a set of XML manifests that cause the appropriate MSI to be run (or not) depending on a set of conditions you define. – DarrellNorton Dec 08 '10 at 14:54
  • dotNetInstaller is tricky and cryptic to use but it seems to get the job done and its free. Thanks. – Tom Kidd Dec 09 '10 at 19:46
0

A solution is to use a custom action which runs the "msiexec.exe /x" command. Make sure it's scheduled after InstallFinalize in InstallExecuteSequence. Also, it's Return should be asyncNoWait (asynchronous execution, do not wait for return).

With these settings the uninstall uses a different asynchronous process, avoiding the conflict.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • For some reason this wouldn't work for me. Might have been the change in InstallScope. In any event afterwards I would wind up with two copies of the software installed, neither of which would work – Tom Kidd Dec 09 '10 at 19:45