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

Sean Hall r.sean.hall at gmail.com
Wed Jul 29 14:22:24 PDT 2020 

> but if Package elements (and BootstrapperApplication) require a Payload
to be specified as the actual installation package, there is a lot of extra
typing.

Maybe there's more typing but it makes the schema much simpler. Also, I
don't like the magic of picking the first payload if the payload
information wasn't given on the package/BA element.

I like the idea of keeping the payload information on the BA element (which
would mean it's now required).

> My example above isn't great because I think it could be easily
implemented using current design with PayloadGroup.

I don't follow. The only way to use a PayloadGroup today would require the
extension to parse it. I don't think an extension should ever be
responsible for parsing a core element. That logic is in Core and should
not be reimplemented because it's subject to change.

<BootstrapperApplicationContainerRef Id="WixstdbaHyperlink" />

Are you expecting the "WixstdbaHyperlink" id to reference something in
Bal.wixext? If there were such a thing, it should be an internal
implementation detail and not directly referenced by user code.

On Wed, Jul 22, 2020 at 9:20 AM Rob Mensching <rob at firegiant.com> wrote:

> > I don't think the ContainerRef with well-known Id is very discoverable.
>
> Yeah. I was thinking the well-known id might become like
> "ProgramFilesFolder". A dev would have to know it's there but once they saw
> it, hopefully it'd pretty clear what it is for but maybe devs get confused
> by "ProgramFilesFolder".
>
> > I'm starting to think we do need to change how BootstrapperApplication
> works.
>
> Absolutely. I'm visual so examples help me a lot. In, v3 defining a BA
> looks like:
>
> <BoostrapperApplication SourceFile='path\to\myba.dll'>
>    <Payload SourceFile='path\to\other.dll' />
>
>
> Using elements, I think the proposal looks something like:
>
> <BootstrapperApplicationContainer Id='MainStuff'>
>    <BoostrapperApplication PayloadRef='BA' />
>    <Payload Id='BA' SourceFile='path\to\myba.dll' />
>    <Payload SourceFile='path\to\other.dll' />
>
>
> That's a lot more boilerplate code for something that is always present. I
> understand the sentiment behind the issue at
> https://github.com/wixtoolset/issues/issues/4183 but if Package elements
> (and BootstrapperApplication) require a Payload to be specified as the
> actual installation package, there is a lot of extra typing. In particular,
> MsiPackage can automatically find its payloads from the package payload so
> a single element is all it needs.
>
> Using an attribute to designate the BA, I think it'd look more like:
>
> <BootstrapperApplicationContainer Id='MainStuff'>
>    <Payload BootstrapperApplication='yes' SourceFile='path\to\myba.dll' />
>    <Payload SourceFile='path\to\other.dll' />
>
> That removes the PayloadRef and Payload/@Id which is good. My concern is
> that "BootstrapperApplication" attribute could be put on any Payload (and
> would show up in Intellisense), even though it could only be used under the
> BootstrapperApplicationContainer element.
>
> So, we could stay with BootstrapperApplication/@SourceFile that would look
> like:
>
> <BootstrapperApplicationContainer Id='MainStuff'>
>    <BoostrapperApplication SourceFile='path\to\myba.dll'>
>    <Payload SourceFile='path\to\other.dll' />
>
> In the most common-case the Id could be optional, so a bundle with a
> custom BA would look like:
>
> <Wix>
>    <Bundle Name="..." UpgradeCode="...">
>       <BootstrapperApplicationContainer>
>          <BoostrapperApplication SourceFile='path\to\myba.dll'>
>          <Payload SourceFile='path\to\other.dll' />
>
> And since most devs use a built-in BA, I'm guessing they'd have something
> like:
>
> <Wix>
>    <Bundle Name="..." UpgradeCode="...">
>       <BootstrapperApplicationContainerRef Id="WixstdbaHyperlink">
>          <bal: WixStandardBootstrapperApplication Theme='custom' />
>          <Payload SourceFile='path\to\Theme.xml' />
>          <Payload SourceFile='path\to\Theme.wxl' />
>          <Payload SourceFile='path\to\custom-header.png' />
>
> And for something more complex where the BA is moved to a Fragment, maybe:
>
> <Wix>
>    <Bundle Name="..." UpgradeCode="...">
>       <BootstrapperApplicationContainerRef Id="MyCustomTheme">
>    </Bundle>
>
>    <Fragment>
>       <BootstrapperApplicationContainerRef Id="WixstdbaHyperlink">
>
>       <BootstrapperApplicationContainer Id="MyCustomTheme">
>          <bal: WixStandardBootstrapperApplication Theme='custom' />
>          <Payload SourceFile='path\to\Theme.xml' />
>          <Payload SourceFile='path\to\Theme.wxl' />
>          <Payload SourceFile='path\to\custom-header.png' />
>
> My example above isn't great because I think it could be easily
> implemented using current design with PayloadGroup.
>
> Sean, do you have a better example that motivates all these changes? I
> feel like I've lost the plot a little bit in the end.
>
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Wednesday, July 15, 2020 3:07 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
>
> I don't think the ContainerRef with well-known Id is very discoverable.
>
> Earlier, you said "We could also decide if BootstrapperApplication element
> should allow children or instead make developer use new
> "BootstrapperApplicationContainer" element." I'm starting to think we do
> need to change how BootstrapperApplication works.
>
> I think we should make the new BootstrapperApplicationContainer element
> have an Id that can then be referenced with
> BootstrapperApplicationContainerRef elements. Require
> BootstrapperApplication to be a child of one of them and get rid of
> BootstrapperApplicationRef. I'm not sure whether to keep the payload
> information on the BootstrapperApplication element or require a single
> Payload or PayloadRef child element. Or maybe get rid of
> BootstrapperApplication altogether and have an attribute for a Payload that
> designates it as the BA.
>
> So for conversion, BootstrapperApplication would be converted to
> BootstrapperApplicationContainer except all of the payload information
> would be moved into a new child BootstrapperApplication/Payload element. I
> think BalExtension has some custom attributes targeting
> BootstrapperApplication, so maybe we would need to keep that element and
> move those as well. BootstrapperApplicationRef would be converted to
> BootstrapperApplicationContainerRef.
>
> I believe this is similar to what Bob was requesting in
> https://github.com/wixtoolset/issues/issues/4183. Making an element act
> as a payload and something else seems to have been a bad design.
>
> On Thu, Jul 16, 2020 at 2:25 AM Rob Mensching <rob at firegiant.com> wrote:
>
> > "BootstrapperApplicationContainer" is fine. I mentally changed
> > everything to "Bundle" but I understand that's not a reality. <smile/>
> >
> > If using a "Ref" is preferred, I could definitely see a case for
> > adding a well-known container name and use ContainerRef* to reference
> > it. This probably isn't as bad as I thought it was since we already
> > have several well-known identifiers out there. This would look like:
> >
> >    <ContainerRef Id="BootstrapperApplicationContainer">
> >     <Payload ...
> >     <Payload ...
> >     <Payload ...
> >    </ContainerRef>
> >
> > Given the number of other well-known identifiers in the world, I could
> > be pretty easily convinced of this latter solution.
> >
> > * plus add ability to have child payloads under ContainerRef
> >
> >
> > -----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 3:23 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
> >
> > 2. I guess I should have gone back and read your previous email. Based
> > on what you said earlier today, it sounded like you wanted to do a
> > ContainerRef with an Id of BundleApplicationContainer.
> >
> > I think it's weird for a non-Ref element to merge, but if you're that
> > strongly against a Ref element that doesn't have an Id then that's fine.
> >
> > I'd rather have BootstrapperApplicationContainer than
> > BundleApplicationContainer unless we're going to rename
> > BootstrapperApplication after all. Which I still don't want to do. I
> > would also go for a different name if someone comes up with a better one.
> >
> > On Wed, Jul 15, 2020 at 8:05 AM Rob Mensching <rob at firegiant.com> wrote:
> >
> > > 1. Okay, I guess I misunderstood the purpose of the Theme attribute.
> > > I thought it was going to be used in the Bal.wixext to create
> > > appropriate payload references.
> > >
> > > 2. I proposed "BundleApplicationContainer" to be the element that
> > > merges together. Same idea (I think) just no "Ref" on the end.
> > >
> > > Open to better names as always.
> > >
> > >
> > > -----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 3:00 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. Look at
> > >
> > > https://github.com/wixtoolset/Bal.wixext/blob/master/src/wixlib/wixs
> > > td
> > > ba.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-architectur
> > > > > > e-
> > > > > > 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/
> > > >
> > > ____________________________________________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> > >
> > ____________________________________________________________________
> > 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