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

[Rob Mensching]

The bulk of the design effort for Burn in WiX v3.x went into the engine. The development experience was definitely second. In fact, when we started, bundles were created by a separate tool, not the candle/light pipeline.

Managed code came even later and again the focus was spent on just making the interaction with the engine work. The development experience was definitely second.

Same for wixstdba.

So, don't necessarily lean on history here. If the experience can best be improved by enhancing Bal.wixext then that is absolutely the best way to do it. We didn't have Bal.wixext for a long time and, IMHO, underutilized in the name of expediency many times (Burn development got pretty hectic for a while at the end).

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Thursday, June 25, 2020 3:16 AM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: [wix-devs] Bal.wixext BA x64/ARM64 support

How do we want to do this? In the extension custom actions, there's a custom element like NativeImage in NetFx. Its compiler calls ParseHelper.CreateCustomActionReference which picks the right Id based on the architecture being compiled.

For the BAs, there is no custom element. The user would manually have to set the BootstrapperApplicationRef Id based on which architecture they're compiling for.

Do we want to create a new element to abstract this away? Should we repurpose the WixStandardBootstrapperApplication/WixManagedBootstrapperApplicationHost
elements for this? It seems like the Bal extension was originally put together with the goal to write as little C# code as possible.
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/