[wix-users] Major upgrade and bundle running in embedded mode results in two ARP entries

[john.pnvn at seznam.cz]

Hello,

we're running Burn bundles in embedded mode and communicate via the pipe 
with the bundle process (using ManagedBundleRunner).

However, we stumbled upon issue with upgrades, when old bundle is not 
uninstalled and as a result there are two ARP entries (e.g. version 1.0 and 
2.0).

The culprit seems to be is inside PlanRelatedBundlesBegin. We've tried 
experimenting with setting ProviderKey for our bundles, but that caused much
more trouble (even though it was supposed to fix our problem according to 
the source of PlanRelatedBundlesBegin function).

We're currently using WiX, Burn version 3.10.2 and one custom (compiler) 
extension. By looking at the WiX repository, we've noticed, that this issue 
was fixed in the following commit:

https://github.com/wixtoolset/wix3/commit/fa972797506baeab2d72a57811dc733852
e65191

SHA-1: fa972797506baeab2d72a57811dc733852e65191


Merging this commit onto our master branch (which is based on origin/master,
i.e. currently 3.10.2 version) fixes this problem. This commit was not 
merged into wix3103 branch, which makes us believe that this won't make it 
into 3.10.3 release.

Although this commit does fix our problem, we're hesitant to actually 
publish updated bundle with Burn having this change applied, since we don't 
know if this causes any more issues down the road (and if there are other 
commits, that we should take).

We did notice one small issue with this change. It's related to patches and 
this is the error:

Error 0x80070003: Failed to create embedded process atpath: <path to cached 
bundle for patch v1.1>

This should reproduce the issue (along with the commit above applied):
- install bundle for product v1.0
- install bundle for product patch v1.1
- install bundle for product v2.0 (major upgrade, new product code, higher 
version, etc.)

What happens during v2.0 install is this:
- product is upgraded to v2.0 (correctly)
- bundle for v1.0 is uninstalled (-uninstall -quiet -burn.related.upgrade -
burn.ancestors=<v2.0 bundle id>
    - during v1.0 bundle uninstall bundle for patch v1.1 is uninstalled
- bundle for patch v1.1 should be installed again
    - this fails, since cached bundle for patch v1.1 was already deleted

Seems like a simple workaround for this is to have our BA only uninstall 
patch bundles, if they're within the major version (i.e. bundle v2.0 should 
uninstall bundle for patch v2.1 but not v1.1). However, similar to Bob 
Arnson's commit, we have no idea, if this might cause any issues in the 
future.

John