Today we had a nice mix of bugs and feature requests that was reminiscent of triage during the WiX v3.x days more so than the past few months of getting WiX v4 out to everybody. Nature is healing.
WiX v5 feature overview, part deux
Last time, we talked about the "epic" I wanted to work on in WiX v5. Today, Rob talked about his plans for WiX v5. My epic consists of several related but generally small features. Rob's planning on one big feature instead: To move bootstrapper applications out of the Burn engine process. That sentence makes perfect sense if you've spent years in the Burn engine. Others might benefit from some more detail.
Today (and yesterday in Burn v3), a bundle contains the Burn engine and, in an attached container, the BA and everything it needs to run. The BA is a DLL that Burn loads and calls into to do all the things a bootstrapper application can do. (That's quite a lot, it turns out.) When you look at a BA like WixStdBA, that's easy: Burn and WixStdBA are both native code, written in C with its venerable low-level API compatibility. It's a tougher story for managed code like C#. Burn has always had support for BAs written for .NET Framework. Sean did a lot of work to support BAs written in .NET Core (but not .NET Core anymore, just plain .NET, distinct from old-school .NET Framework). Supporting managed-code BAs requires some kind of extra native code to host the managed code and translate messages between the native-code Burn API and the managed-code BA. As demonstrated with WiX's two distinct flavors of managed-code BA hosts, that code is at a low level and is specific to the runtime it's hosting. Other managed languages are out of luck.
So what if BAs are processes (.exes) instead of DLLs? One immediate effect is that Burn wouldn't need any of its solutions for hosting managed code: As long as you can compile an .exe, Burn can launch it. That not only maintains support for .NET, but also opens up support for Rust, Go, Swift, Python, PowerShell, batch files...wait, probably not batch files.
There are other benefits, too. For example, today, when a BA crashes, it takes down Burn with it. With BAs in their own processes, Burn could theoretically recover more gracefully from a rudely-crashed BA. There's extra code to handle BAs as DLLs that could just be thrown away (or responsibly recycled).
If you don't write custom bootstrapper applications, none of this will affect you, though you'll still get the indirect benefits.
More details, including, of course, a WIP, to come.
Issue triage
Support logging to console in burn, from @nirbar, is a request to add a new bundle command-line switch to send Burn's logging to the console, in addition to its current destination, everyone's favorite log file. Rob objected, not wanting to add a new, edge-case, type of logging to the Burn engine itself. Instead, he suggests that "embedded mode" should be enhanced to cover the full extent of logging. Today, embedded mode lets you run a bundle and get progress information sent to you. It's intended for headless-but-monitored mode, where there is no user interaction but there might be someone watching, waiting, and wondering what's taking so long. The embedded protocol lets you helpfully report that data to a worried user.
Control output for Harvest Tasks in Wix V4, from @MddMBorg, requests support for specifying the name and path of the WiX source file generated during Heat harvesting. That's a perfectly cromulent feature request, so we opened it as
up for grabs.HarvestSuppressUniqueIds does not take effect under HarvestDirectory item., from @mobigliani, says it would be cool if the global properties the Heat targets support could also be specified as metadata in individual items. Sure, that sounds fun, so this issue is also opened as
up for grabs.Substitution does not create ModuleSubstitution table when building Merge Module, from @rsdk-vag, reports a regression (:sad_face_emoji:) in WiX v4 for one of the more obscure edges of merge modules. Rob volunteered to take a look at this one.
Page Not Found: Schema URIs are not URLs, from @barnson, came about when I was reading the WiX documentation -- something I encourage everyone to do because otherwise why bother writing it?! -- and noticed that the namespace URIs were turned into hyperlinks by the documentation tooling. XML schema namespace URIs are just unique identifiers; even though they look like URLs, I assure you, they're not. I hated to perpetuate that myth, so I made the documentation tooling stop turning them into hyperlinks.
Merge modules don't extract during decompilation and
wix msi decompile -xremoves modularization GUIDs from object fields, both from your humble reporter, are a result of some fairly low-level work I'm doing for a FireGiant customer, where I was displeased to discover that the newwix msi decompile -xfeature was buggy in a couple of different ways. I've fixed the first one and will fix the second one shortly.error WIX0204: ICE80: This package contains 64 bit component 'Foo' but the Template Summary Property does not contain Intel64 or x64., from @twest820, suggests that an ICE validation error message could be worded better. I don't disagree but as the ICEs are proprietary, we can't change the wording. We could reimplement ICEs in WiX itself, which would let us use whatever words we want (more or less).
Page Not Found: /documentation/manual/v3/main/, from @robin2777, found an old link to the WiX web site. Well, not that old -- it was valid until we reorganized to add the WiX v4 documentation. So I volunteered to add a redirect.