[wix-devs] Bal.wixext BA x64/ARM64 support
Rob Mensching
rob at firegiant.com
Wed Jul 22 08:20:34 PDT 2020
> 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