Skip to content
Richard Martin edited this page Jul 30, 2024 · 3 revisions

While code changes between v4 and v5 BAs are minimal, the biggest change is that your BA is now running out of process. Your BA is no longer a library referenced by Burn, but a stand-alone Windows app.

Previously, if either Burn or your BA crashed, your BA would get unloaded from memory when the Burn BA host was shut down. That's no longer true. If Burn crashes, your BA could be left running. This is more troublesome if your BA has trouble getting started. Burn may crash and exit because your BA didn't respond during startup. Your app could be left running as a background process, so keep an eye on Task Manager as you develop and test your BA.

Bootstrapper Changes

The code for the BA is mostly identical to the WiX 4 solution.

The BA is now an EXE

One of the challenges to using a self-contained .NET Core BA is that a large number of dependencies are generated when it's published. Now that the BA is built as an EXE, I was hoping this issue could be addressed by building a single-file, self-contained BA. Unfortunately, I couldn't get the BA to publish as a single file. I suspect the reference to WinForms (for that pesky window HWND) is the culprit, but I didn't try very hard to chase the problem down.

Normally, a WPF app uses a System.Windows.Application instance to host the app. When starting a WPF project, this is scaffolded for you in App.xaml. Burn doesn't play nice with this class. Instead, use a Program.Main method as the entry point for your WPF BA app, as demonstrated in the sample code.

Other Differences

  • The BaseBootstrapperApplicationFactory class is deprecated. WiX no longer requires a factory to build the BA.
  • The WixToolset.Mba.Host.config file is deprecated. You no longer need to supply this.
  • The WixToolset.Mba.Core NuGet package has been replaced with WixToolset.BootstrapperApplicationApi and the namespaces changed. Most of the differences between the v4 and v5 sample solutions are to accommodate the namespace change.
  • SetUpdateBegin and SetUpdateComplete BA events were removed.

There are other minor differences, but nothing that would hinder updating a BA that targets WiX 4 to one that targets v5.

Bundle Changes

  • To get access to the language features introduced with WiX 5, use the WixToolset.Sdk/5.0.0 project SDK like the sample Bundle.wixproj .
  • In Bundle.wxs , authoring the BootstrapperApplication is now simpler.
    • You no longer need to reference a bootstrapper host.
    • Reference your BA's EXE using the SourceFile attribute.
      <BootstrapperApplication SourceFile="$(var.Bootstrapper.TargetDir)Bootstrapper.exe" bal:CommandLineVariables="caseInsensitive">

If I were wiser, I would have provided a .NET Framework BA for the sample. I guess I'm still hoping I can get a practical .NET Core solution working one day. Consequently, like the WiX 4 .NET Core solution, the project file is more complex than it needs to be. It uses Heat and XSLT to generate all the Payloads to pull in the dependencies.

If your BA is based on .NET Framework, then I suggest using the Bundle project file from the WiX 4 Framework sample as a reference instead. Just update the project SDK to WixToolset.Sdk/5.0.0 and the NuGet references to their v5 counterparts.

Clone this wiki locally