[wix-devs] Bal.wixext BA x64/ARM64 support
Sean Hall
r.sean.hall at gmail.com
Sun Aug 2 16:41:23 PDT 2020
I updated the WIP with examples. If that's not enough, I'll need you to
provide an example because I don't know what you're talking about with v3
and PayloadGroups.
On Sat, Aug 1, 2020 at 12:06 PM Rob Mensching <rob at firegiant.com> wrote:
> > 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