[wix-users] Bundle and Optionally RelatedBundle

[Hoover, Jacob]

I think in 4.x Sean has already done the work to expose this info to BAF's.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Edwin Castro
Sent: Thursday, August 31, 2017 11:17 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Bundle and Optionally RelatedBundle

I certainly would welcome the added complexity to get "engine extensibility parallel to the BA for business logic separate from UI/UX". Perhaps adding more extensibility points to BAFunctions would get us mostly there.

I've wanted to a way to use wixstdba but run just a little bit of code before any packages are applied and then a tiny bit of code after all packages are applied but BAFunctions doesn't give me a way to do that. At other times, I've needed complicated logic to decide whether a package should be installed which should logically be decided in a custom BA but all I really wanted was a way to extend wixstdba to make that decision but, again, BAFunctions didn't let me make that decision.

--
Edwin G. Castro



On Wed, Aug 30, 2017 at 7:33 PM, Bob Arnson <bob at firegiant.com> wrote:

> It's an edge case for something living in the engine, imo. That said, 
> it's a good example of business logic that should be easier to 
> customize than "write a BA." Maybe BAFunctions are sufficient? I've 
> thought before that having engine extensibility parallel to the BA for 
> business logic separate from UI/UX is worth investigating...Not sure 
> it's worth the complexity, though.
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On 
> Behalf Of Hoover, Jacob
> Sent: Wednesday, 30 August, 2017 11:08
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: [wix-users] Bundle and Optionally RelatedBundle
>
>   Is there any way for a bundle to remove a specific version of 
> previous bundles, without a custom BA and without causing an 
> interdependency with the next version of a bundle?  The current 
> RelatedBundle/Upgrade causes any future bundles which also intend to 
> upgrade a specific bundle to also upgrade the related bundles.  IE, bundles A (1.0), B (2.0), and C (3.0).
> If I have B and C both being related to A, when C is installed it will 
> remove B. I understand the "why" behind this, as we want bundle A to 
> be able to block when future bundles are created, however I'd like to 
> allow the user to control the removal of previous bundles.
>
>   I know I could easily handle this with a custom BA, but to me it 
> would be nice if I implemented an optional option to related bundle to 
> conditionally drive the behavior.  IE, <RelatedBundle Id="A"
> Action="OptionalUpgrade" Condition="UNINSTALL_PREVIOUS" />
>
> Thanks,
> Jacob
>
>
> ____________________________________________________________________
> 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/