1

I have created two custom applications with two separate wix bootstrappers.

The applications can be installed in any order and in any combination.

The structure of the two bundles then look like the following:

Bundle A

  • Application A.msi
  • Dependency.msi

Bundle B

  • Application B.msi
  • Dependency.msi

The problem arises when I uninstall whichever application I installed first, as it will uninstall the dependency out from under the other application, causing one or the other to fail at runtime.

How can I ensure that my installer will not uninstall the dependency if the other program has been installed? Will I need to write a custom action for uninstall?

I'm very new to Wix bootstrappers. I have only ever written simple msi installers before, so I'm not sure where to start and documentation seems to be spread pretty thin.

wdonahoe
  • 1,043
  • 1
  • 10
  • 22
  • Ran a quick test, and it seems to work. Are the **`Dependency.msi`** files identical in both Bundles, or are there differences in for example package code or product code? – Stein Åsmul Feb 12 '19 at 02:30
  • Can't look more at this at the moment, the advice below is best effort. [`Please have a read here about major upgrade problems`](http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundles-shared-packages-reference-counting-and-major-upgrades-td7583180.html). Make sure you test upgrade scenarios. – Stein Åsmul Feb 12 '19 at 03:04

1 Answers1

0

UPDATE: Please let us know how you are testing the bundles. Virtuals? In what scenarios do you see the problem?

I am not a bundle expert, but here goes (will verify some of this, just dumping this in for now):

Burn Reference Counting: My quick smoke test seemed to work - the Dependency.msi remained when it was supposed to?

Are the Dependency.msi files identical in both Bundles, or are there differences in for example package code or product code? Please have a read here about major upgrade problems. Make sure you test upgrade scenarios.

Original Answer:

Merge Module / WiX Include Files: You can merge the dependent setup's components into several MSI files using merge modules or WiX include files. Both merge modules and WiX Include Files get merged into setups at compile time. This way the reference count for each component will be two when both main setups are installed. Uninstall will then not remove the installed components until all setups who refer to them are uninstalled.

  • WiX Include Files basically work like normal header files include in C++, it is a preprocessor operation - essentially just string imports. You include the same WiX snippet in many setups. This is flexible. It is code reuse and not binary reuse. The result is the same as for merge modules - components are uninstalled when all instances are uninstalled.

  • Merge Module are small MSI fragments that merge at compile-time so you can inject shared, dependency components into several setups. The merge module is merged in as a whole. Newer merge module versions merged into newer setups will upgrade shared files for all installed applications (provided you design the merge module correctly). Binary reuse.

  • Chris Painter's tutorials for IsWiX shows how you can use merge modules: https://github.com/iswix-llc/iswix-tutorials.

Permanent: You can set the Dependency.msi setup to be permanent. That means it won't ever be uninstalled. Upgrade-ability must be tested.

One Bundle / One MSI: I suppose you can merge all setups into a single setup.exe bundle? You can also merge all MSI files into a single setup.msi using WiX include files or merge modules. Almost never the right thing to do in the real world: Wix to Install multiple Applications.

Condition: There is a condition you can add to the MsiPackage element. It looks like it can not be used for your purpose. Will check.

Deployment Technology: Alternative deployment technologies are not great.

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164