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 <[email protected]> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
