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

Reply via email to