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

Rob Mensching rob at firegiant.com
Sat Aug 1 11:06:09 PDT 2020 

> 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).
> ...
> 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.

A couple examples would probably help me catch up with your thinking. I believe I've fallen back too much into how things are done in v3 (with PayloadGroups) and I'm missing the core problem now. Examples are often really helpful for me to understand what the language changes look like.


-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, July 29, 2020 2:22 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

> 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/wi
> > > xs
> > > 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-architect
> > > > > > ur
> > > > > > 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/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/

More information about the wix-devs mailing list