Sorry to revive an old post, but as there is still no native support for this as of WiX 3.10, I thought I would post my work-around.
The caveat to this method is that double-clicking a package that you've just installed will not bring up the usual 'modify, uninstall' dialog. What I've done to handle this is put in a <bal:Condition> which instructs the user to use 'Add Remove Programs' if they wish to invoke the uninstall or modify functionality.
The reason I need this at all, instead of just incrementing Version to perform an upgrade, is that we have online and offline bundles. I want to prevent them from being installed simultaneously.
Another thing that this approach requires is that your bundle version ID matches your MSI version ID. Enough disclaimers, here's the approach:
Create a Product search, but importantly, use the UpgradeCode for your MSI package, not for the bundles! ProductSearch will never find your Bundle's GUID because the Bundle is an .exe and not an MSI.
<util:ProductSearch
Variable="BundleAlreadyInstalled"
UpgradeCode="MSI-GUID-NOT-BUNDLE-GUID"
Id="BundleAlreadyInstalledSearch"
Result="version"
/>
Next, inside your <bundle> elements, add the following:
<Variable Name="CurrentVersionNumber" Type="string" Value="$(var.Version)" />
<bal:Condition Message="Tell your user to use Add Remove Programs here.">
NOT WixBundleAction = 5 OR NOT BundleAlreadyInstalled = CurrentVersionNumber
</bal:Condition>
The core of the hack here is that we are using the MSI's Version (which as I said must match the Bundle's Version for this reason) as the key indicator to whether this bundle is present on the target system.
If you don't include NOT WixBundleAction = 5 you will not be able to uninstall the application, which is kind of important.
As for the second part, we want to specifically detect whether this version is already installed. Upgrades and downgrades will fail this test, which is what we want because the normal logic would kick in and perform your upgrade/downgrade.
Without this bit of logic, it was possible for my users to install both the online and offline versions of the bundle simultaneously. The primary reason for that is that the Bundle@Id is generated by WiX. Another more subtle problem that this fixes is that simply rebuilding a Bundle without modifying the Version will also allow you to install it side-by-side! You will get duplicate entries in 'Add Remove Programs' for all of these.
These problems are completely prevented by these few lines of code. As I mentioned, the trade-off is that installing, and subsequently running the exact bundle again will not trigger the uninstallation dialog, but this is a whole lot easier to live with than duplicate ARP entries. Especially since you can just provide instructions in the error message.
bal– Participation