-
Notifications
You must be signed in to change notification settings - Fork 1
WiX 5
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.
The code for the BA is mostly identical to the WiX 4 solution.
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.
- 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
andSetUpdateComplete
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.
- 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 Payload
s 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.