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

Sean Hall r.sean.hall at gmail.com
Tue Jul 14 15:00:03 PDT 2020


1. Look at
https://github.com/wixtoolset/Bal.wixext/blob/master/src/wixlib/wixstdba.wxs.
The theme, loc file, and logo are all customizable through WixVariables.
It's also inserting custom data into the BA manifest. This is not something
I want to address in this issue.

2. Does anyone else have any other ideas? All of mine are getting shot down.


On Wed, Jul 15, 2020 at 7:35 AM Rob Mensching <rob at firegiant.com> wrote:

> 1. Why is this hard? If there is going to be an enum Theme attribute,
> ensuring the value is copasetic with the ThemeFile attribute isn't a big
> deal. Or am I missing something.
>
> 2b. We should not introduce a "Ref" element without "Id".
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Tuesday, July 14, 2020 2:31 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. How strongly do you feel about that? This is a rabbit hole I don't want
> to go down.
>
> 2b. There is always exactly one UX container in a bundle and that's what
> BootstrapperApplicationContainerRef would be referencing. I get that we
> haven't done that before but I think it makes sense to bake the Id into the
> element name here.
>
> On Wed, Jul 15, 2020 at 5:03 AM Rob Mensching <rob at firegiant.com> wrote:
>
> > 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/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>



More information about the wix-devs mailing list