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

Bob Arnson bob at firegiant.com
Fri May 27 07:33:48 PDT 2016


I can't really comment on a private fork as I don't know the details about it. I'm not really clear that the v3.11 is buggy; can you open an issue with all the Burn logs and descriptions of each bundle? 

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

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/"

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


More information about the wix-users mailing list