Wix Burn: Custom Bootstrapper upgrade but Installs side by side with older version

Question

I'm struggling with my Custom Bootstrapper Upgrade issue. By following this thread, I'm using LaunchAction.Install.

This does Upgrade the Product as well as Boostrapper, but older Bootstrapper remains there, as shown in following screen shot.

If I invoke ver 1.0.0.0 from here, it would display Dialog to Install, but would do nothing. However, invoking ver 1.0.1.0 would give me the option to Uninstall the product. However, upon Uninstall, it would only remove itself, and "My Product" is left behind.

I also tried with

_bootstrapper.Engine.Plan(LaunchAction.UpdateReplace);

and

_bootstrapper.Engine.Plan(LaunchAction.UpdateReplaceEmbedded);

but it has no effect.

Question: How to upgrade older installation without falling in above situation? Can anyone please provide a working example of CustomBA upgrade?

Regards

Dosser

Answer 1

Check the PlanRelatedBundle event. Its where you can tell the Engine what to do with the old bundles.

If you want a Bundle to replace the old one the UpgradeCode should be the same for both. In this case it will uninstall the old bundle as default. Also the old bundle needs to support quiet uninstallation since it will be called with the argument /quit after installing the new one.

You can check it in the BootstrapperApplication.Command.Display property. It should be "Embedded" if its called from another Bundle. The BootstrapperApplication.Command.Action is set to "Uninstall" in this case.

If nothing of this works check the logs that are created in the AppData\Temp folder.

Donell

WIX itself uses a custom BA, so looking at the WIX source code for how it handles a command line uninstall is a good place to see an example. – Analisaanalise

Answer 2

I also experienced this problem. I had to write my own managed bootstrap application. I had a bug where I was kicking off the Plan() phase before the Detect() phase finished.

Hence the old bundle was not uninstalling as it should have.

It is good practice to implement a handler for every event that the Bootstrapper offers. Write a log entry in every handler listing out the arguments supplied to the handler. It makes chasing down errors a lot easier.

In my case I was migrating from InstallShield 2009 to WiX 3.10 and I had to write my own managed bootstrapper because I had to conditionally install SQL Server express based on user inputs from a fancy WPF boostrapper.

Kery