Do you like issue triage? Because we got ya covered with so much triage: Incoming issues, v4.0.1 issues, future v5 issues, and issues even more futurer than that.

WiX v4.0.1

Our current plan to ship WiX v4.0.1 on 5-June-2023 remains our current plan. The rate of incoming bugs has slowed and the rate of bugs important enough for WiX v4.0.1 has plummeted. So we'll fix a couple of remaining bugs and cherry-pick the fixes in a bit under three weeks.

WiX v5

We triaged the remaining issues in the v.Future milestone to push those with volunteers into WiX v5 or to mark them up for grabs for issues to find their own volunteers for WiX v5 or later. The WiX v5 schedule remains unchanged:

  • v5.0.0-preview.1 on 5-Jan-2024
  • v5.0.0-rc.1 on 5-Feb-2024
  • v5.0.0-rc.2 on 5-Mar-2024
  • v5.0.0 on 5-Apr-2024

Issue triage

  • mbanative.dll isn't automatically included in .NET Framework MBA UI payloads, from @nirbar, suggests that mbanative.dll, which is required for managed-code bootstrapper applications, ought to be automatically included as a payload when specifying that your bundle is, indeed, using a managed-code bootstrapper application. It's a fine suggestion, complicated by the need for an architecture-specific copy of mbanative.dll. Rob volunteered to investigate as part of his work on BAs in WiX v5.

  • -d does not work when using dotnet tool wix, from @phillip-haydon, describes an oddity when using a project-local installation of WiX as a .NET tool. The -d switch (to define a preprocessor variable in WiX) appears to be hijacked when executed in a dotnet wix ... command line. It works fine when using WiX as a global .NET tool. The long switch -define works, so that's the workaround until Rob finishes his investigation in WiX v5.

  • DirectoryRef/@FileSource should default to that of reference Directory/@FileSource, from @dmcmenamin-kt, requests that a Directory/@FileSource value work when the directory is later referenced via DirectoryRef. Today, FileSource attribute values are used only by the children of the element when compiled; the values are not persisted, for example, in a .wixlib for later consumption. I created a tracking issue for this and a related issue to see if there's a holistic approach to the many and varied ways you can specify source paths for package payloads.

  • Building Bootstrapper generates WIX0352: Unable to read package error, from @chrpai, reports that an MSI package without components cannot be included in a bundle. While a package without components sounds impossible, it's technically possible -- though ugly. Still, WiX shouldn't crash on valid packages, so we took this for WiX v4.0.1.

  • Wix v4.0.0 HarvestProject does not harvest referenced dependencies, from @Retik, suggests that the dependencies of a project should be harvested as well as the project's output. That seems reasonable but isn't what's happening. Project harvesting doesn't always follow the laws of physics, so it's not clear whether the dependency outputs should be included in the output groups being harvested. The issue is up for grabs for someone to investigate.

  • Empty CustomTable not created in MSI, from @chrpai, reports that a CustomTable with no child Row elements does not create an empty table in the resulting MSI package. That's actually by design. In WiX v3, CustomTable served both to define a custom table (with Column child elements to describe the table's columns) and, optionally, as a reference to a custom table defined elsewhere. WiX v4 clarifies the purposes into two elements: CustomTable to define the table and CustomTableRef to reference it when adding rows.

  • Fatal Error when decompiling Dialog table, from @mamurph, reports a crash when using wix msi decompile. Crashes will not stand, so this issue will be fixed in WiX v4.0.1.

  • Custom Extension causes WiX to have unhandled System.ArgumentNullException, from @chrpai, reports a crash when using a custom WiX extension. As you might have gathered, we're not a fan of crashes...but that's only for our own code. WiX extensions are deeply integrated into the WiX build pipeline and as they run inside the WiX process, an extension that crashes will also crash WiX. Luckily, you'll get a reasonable stack trace when running from the command line -- both from MSBuild and when using the WiX .NET tool. And take it from someone who's done a lot of work inside WiX extensions, the debugger is your friend.

  • SignContainers is infunctional for detached bootstrapper containers, from @nirbar, reports a problem when signing detached containers in a bundle. It's entirely possible there is a missing runtime test that exercises signed detached containers, given that they are relatively rare. I bravely volunteered to investigate for WiX v4.0.1.