[wix-devs] Bal.wixext BA x64/ARM64 support

[Rob Mensching]

1. I missed that "Theme" was purely an add. In that case, Theme="custom" (or something to that effect) could be required to use "ThemeFile".

2a. Yeah, that's busted behavior. We shouldn't do that.

2b. "Ref"s have "Id"s and reference "something". We don't have many elements that merge but I think that makes most sense in this case. The alternative is to use a "ContainerRef" element to a well-known name--like "BundleApplicationContainer"--and allow ContainerRef to have child payloads but that isn't more discoverable.


-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, July 8, 2020 3:37 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Bal.wixext BA x64/ARM64 support

1. I'm just translating what was happening in v3. When picking an Id to reference, there was no vanilla WixStandardBootstrapperApplication Id. You can always overwrite the theme using the existing ThemeFile attribute.

2a. This problem you're worried about already exists is a slightly different form - https://github.com/wixtoolset/issues/issues/5273.

2b. I was thinking about merging, which is why I suggested BootstrapperApplicationContainerRef not BootstrapperApplicationContainer. I think I prefer this one.

On Thu, Jul 9, 2020 at 8:09 AM Rob Mensching <rob at firegiant.com> wrote:

> 1. I'm a little concerned about making Theme an enum. I guess we 
> couldn't add a Theme without update the extension, so the enum could 
> be enhanced at that time. But isn't it possible to provide your own custom theme in v3?
>
> 2. I'm waffling between two options for including more payloads into 
> the BA container:
>
> 2a. The "BootstrapperApplication='yes'" option - this is probably the 
> easiest to slip into the system. I worry a bit about what happens if 
> you create a payload group with mixed use of BootstrapperApplication, like:
>    <PayloadGroup Id="Stuff">
>      <Payload Source="bastuff.bmp" BootstrapperApplication="yes" />
>      <Payload Source="notbastuff.bmp" />
>    </PayloadGroup>
>
> 2b. Introduce "BootstrapperApplicationContainer" (or better name) 
> element
> - this would allow child Payload and PayloadGroups elements and all 
> resulting child Payloads (after flattening) would be 
> BootstrapperApplication data. That avoids the problem above. We would 
> then need to decide if "BootstrapperApplicationContainer" can be 
> defined multiple times and silently merge or if there can be only one. 
> We could also decide if BootstrapperApplication element should allow 
> children or instead make developer use new "BootstrapperApplicationContainer" element.
>
> If we went with 2b. I think I'd go with silent merging (like the UI
> element) and allow BootstrapperApplication to continue to act as a 
> BootstrapperApplicationContainer. That should also be pretty minimally 
> disruptive, I think.
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Sean Hall via wix-devs
> Sent: Wednesday, July 8, 2020 5:50 AM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Bal.wixext BA x64/ARM64 support
>
> I created a WIP for this at
> https://wixtoolset.org/development/wips/6209-multi-architecture-bal/. 
> We need to decide how to expose the UX container in authoring.
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/