Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Burn 3.7 package planning differs from 3.6 during Modify; InstallCondition not respected #3978

Closed
wixbot opened this Issue Apr 19, 2013 · 3 comments

Comments

Projects
None yet
2 participants
Collaborator

wixbot commented Apr 19, 2013

I use a custom managed BA and recently upgraded from WiX 3.6 to 3.7.
The chain contains MSIs only. (The custom BA allows for package selection, i.e. not all MSIs in the chain will be necessarily installed after the BA run finishes.)

The behavior can be reproduced independently from my custom BA using a very simple authoring containing dummy test MSIs with install conditions that are trivially true or false.

To reproduce, I install the bundle, then re-run the BA to modify the existing installation, and observe the planned states for a package that is absent:

In 3.6, the behavior is as follows:

If the install condition evaluates to true, the log states:

Detected package: ThirdParty, state: Absent, cached: None
[...]
Planned package: ThirdParty, state: Absent, default requested: None, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None

If the install condition evaluates to false, the log states:

Detected package: Prereq.x86, state: Absent, cached: None
[...]
Planned package: Prereq.x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None

(Since the install condition itself is not directly accessible via the managed API, I therefore took "default requested: Absent" to mean that it evaluated to false, and true otherwise.)

In 3.7 (and the current 3.8 beta builds), the behavior has changed:

If the install condition evaluates to true, the log states:

Detected package: ThirdParty, state: Absent, cached: None
[...]
Planned package: ThirdParty, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None

If the install condition evaluates to false, the log states:

Detected package: Prereq.x86, state: Absent, cached: None
[...]
Planned package: Prereq.x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None

The problem is that the default request is now "Absent" in both cases, and I have no way of telling the difference between a package that shouldn't be installed at all because its install condition failed, and a package that simply wasn't installed last time, but is allowed to be added later. (Therefore I can't override the planning in the BA either.)
While the actual execute action is the same (i.e. "None"), I'd even argue that requesting "Absent" is wrong: Burn shouldn't order packages to be absent per default if their install condition has been met.

This completely breaks my workflow; I use the default request to enable/disable selection options in the UX. Please restore the 3.6 behavior, or, if there is a good reason for it which evades me, provide some other means to access the result of the install condition evaluation (during Detect, maybe?)

Originally opened by vol714 from http://sourceforge.net/p/wix/bugs/3275/

Collaborator

wixbot commented Oct 8, 2013

Originally changed by barnson
Area set to burn
Release changed from v3.8 to v3.x

Collaborator

wixbot commented Apr 27, 2014

Originally changed by rseanhall
AssignedTo set to shall

Collaborator

wixbot commented May 1, 2014

Added InstallCondition to BootstrapperApplicationData.xml. Pull request at wixtoolset/wix3#21 accepted.

Originally posted by rseanhall
Release changed from v3.x to v3.9
Resolution set to fixed
Status changed from Open to Resolved

@wixbot wixbot added bug burn labels Dec 20, 2015

@wixbot wixbot added this to the v3.9 milestone Dec 20, 2015

@wixbot wixbot closed this Dec 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment