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

Thu May 26 02:28:12 PDT 2016

We didn't try that scenario with WiX v3.11. There were more changes to Burn 
since that commit, so we're unsure about the stability. However, those 
changes don't seem to include anything related to planning these related 
bundles, so it's hard to justify going through the pain of merging all the 
changes.

However, we did try using vanilla WiX v3.11 (current version from develop 
branch) and removed all our custom stuff (extension, BA), that could not be 
used without our changes to WiX and Burn. Surprisingly patch bundle install 
was planned *before* uninstall of bundle v1.0. In our case, the order was 
reversed, that's why the Burn could not launch patch bundle anymore (since 
the executable did not exist anymore).

What's even more weird, in case of current vanilla WiX v3.11 that patch 
bundle was detected *before* before v1.0 bundle.

Generally, the actions taken on v2.0 install were slightly different:
- product is upgraded to v2.0 (correctly)
- bundle for patch v1.1 is installed again (-quiet -burn.related.patch -
burn.ignoredependencies=<v2.0 bundle id> -burn.ancestors=<v2.0 bundle id>)
    - v1.1 patch bundle is detected as dependent, no action is taken
    - v2.0 bundle is detected as dependent, no action is taken (because it 
was previously scheduled)

    - patch v1.1 bundle does literaly nothing (as opposed to our case (WiX v
3.10.2 + our changes + your commit), when it removes package dependency for 
the patch itself and bundle dependency provider for patch bundle)
- bundle for v1.0 is uninstalled (-uninstall -quiet -burn.related.upgrade -
burn.ancestors=<v2.0 bundle id>
    - patch v1.1 bundle is NOT uninstalled, because it finds one dependent 
(the v2.0 bundle)
    - this makes sense, since the dependency was added before patch v1.1 
bundle was installed again

v2.0 bundle uninstall is rather simple:
- patch v1.1 bundle is uninstalled (-uninstall -quiet -burn.related.patch -
burn.ignoredependencies=<v2.0 bundle id>;<v2.0 product code> -burn.ancestors
=<v2.0 bundle id>)
    - dependent v2.0 bundle is skipped, since it was previously scheduled
- product v2.0 is uninstalled

Our opinion is that root cause of this behavior could be that the patch 
bundle was detected before v1.0 bundle (and not the other way around as in 
our case). Again, we don't see anything in commits since WiX v3.10.2 that 
could affect bundle/package detect mechanism.

What do you think might cause this?

Also what is your recommendation for the major upgrade scenario and multiple
ARP entries? Should we incorporate your commit (and hack/fix the 0x80070003 
error) or should we wait for WiX v3.11? For us, having patch v1.1 bundle 
uninstalled only when v2.0 bundle is uninstalled, is much smaller issue than
multiple ARP entries (it might be possible to force patch bundle uninstall 
during v2.0 bundle install). The problem is that we would rather have this 
issue resolved sooner rather than later.

-----Original Message-----
From: Bob Arnson <bob at firegiant.com>
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Sent: 25. 5. 2016 18:09:05
Subject: Re: [wix-users] Major upgrade and bundle running in embedded mode 
results in two ARP entries

"Is the patch 0x80070003 problem only present with commit fa972797506baeab2d
72a57811dc733852e65191? That change is included in WiX v3.11; it was made 
after WiX v3.10.1 so wasn't included in the security fixes of v3.10.2 or v
3.10.3.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of
john.pnvn at seznam.cz
Sent: Wednesday, 25 May, 2016 10:57
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: [wix-users] Major upgrade and bundle running in embedded mode 
results in two ARP entries

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

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.
com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.
com/"