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