Sorry, no. In fact, it’s still in the old codebase. But if it needs fixing now
hopefully what I wrote below helps. I’m not sure I can get more specific than
that.
- Heath from Windows 8
From: Rob Mensching
Sent: March 1, 2013 2:48 PM
To: Heath Stewart, Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Should BA be allowed to change dependency manager
decisions?
I can't think of a scenario where overriding the dependency manager is a good
thing. The engine should handle all the internals correctly and have (or ensure
it keeps) the information to log the correct output.
I'm curious, do you have an ETA to send the pull request to fix the bug?
On Fri, Mar 1, 2013 at 1:27 PM, Heath Stewart <hea...@outlook.com> wrote:
I made a fix to the internal sources that, if the dependency manager changed
the execute and action states, sets the patch’s transforms as well (the reverse
of this code exists for slipstreaming near the bottom of mspengine.cpp already)
but the log still shows that the default and ba-requested action is Absent in
the following scenario:
1. Install baseline.
2. Install patch bundle with MSP1 (with ref-counting provider key).
3. Install upgrade patch bundle with MSP1 (i.e. same one, same provider
key) and MSP2.
Because the transforms’ states are not showed and the logging that is displayed
is based on the default states (which a BA would typically pass through), the
log ends up showing something like this in step 3:
Planned: foo_patch; default requested: Absent; ba requested; Absent; execute:
None; dependency: Unregister
The default package request action is almost a 1:1 for the bundle action and
I’m not sure we’d want to change that, but if DependencyCalculatePlan ran
before the engines’ *CalculatePlan functions at least the BA would get the
default requested state (which maybe we could even change in the engine rather
than completely re-ordering the function calls) based on the dependency manager.
The downside (?) is that BAs could override the dependency manager. Maybe that
should be allowed (I know we had discussions on past Thursday nights about
this), but I’m more concerned about BAs that “accidentally” override the state
and ruin ref-counting for all bundles of shared packages/providers.
What do people think? Is that a downside? Should BAs be allowed to override the
dependency manager?
Another option would be to call DependencyCalculatePlan first so the BA gets
the default requested state, but if BURN_PACKAGE::fDependencyManagerWasHere is
set when just override the BA anyway – at least the log would more accurately
show what Burn thinks the default request state should be (i.e. we’d still
override that).
Heath Stewart
VS Pro Deployment Experience, Microsoft
http://blogs.msdn.com/heaths
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs