After a couple of postponed meetings, we're back today to triage a bunch of bugs opened by a bunch of suspicious characters (Sean, Rob, and me). And oh yeah, we have a date for WiX v4.0-preview.1. Read on for details.

Issue triage

  • Burn does not repair an MSI when slipstreamed with a minor update patch, from @rseanhall, is back for discussion after I spent some time investigating and re-learning gory details about patching I'd suppressed from a former life. The short version of the investigation is that Burn's behavior is consistent with how it handles MSI packages and there is likely enough information available to Burn that it could determine whether an installed product is patched to the version of the product-and-patch combination in a bundle. However, it's a nontrivial amount of effort, so something we should design in a future release.

  • WiX should provide default feature, from @barnson, was an idea that came to me while watching Rob's other streaming series and thinking about creating templates for WiX v4: We love removing boilerplate when we can and one obvious one still remaining is the feature tree. Lots of people use single-feature packages and having to author an XML block for a feature and (typically) a ComponentGroupRef or two, is boilerplate we could eliminate. And we will, and more on top of that, in a future release.

  • UICompiler custom actions duplication, from @StefanStojanovic, reports a problem with the WixUIExtension compiler extension in WiX v4: With platform-specific custom actions, we need a way to "inject" them into a package using the WixUI dialog sets. The compiler extension does that but that can lead to duplicate custom action symbols; @StefanStojanovic provided a pull request to fix this problem. Then Sean pointed out that it's still possible to run into this problem, depending on how the authoring is structured. Unfortunately, Sean is right and neither of us came up with a way to avoid the problem; it's a more basic problem when you have a matrix of symbols that need to be unique and specific but consumed generally. This issue is about the matrix of platforms for custom actions but we see it also for localized content. This general problem is one we think we can solve in a future release of WiX. For this specific problem, we'll narrow it as much as we can for WiX v4.

  • Standardize on WiX v4 on .NET 6, from @robmen, says we should move WiX v4 from targeting .NET Core 3.1 to .NET 6, which is a long-term servicing release and will be supported until November 2024. As .NET Core 3.1 goes out of support this December, it's a no-brainer.

  • Move WixVersion to a new WixToolset.Versioning, from @robmen, is a bit of housekeeping following the party of introducing semantic-version-style versioning to Burn. To let managed bootstrapper applications take advantage of WiX's managed code for versioning without having to bring along all the WiX build tooling stored in the WixToolset.Data assembly, Rob moved the versioning code to its own svelte assembly.

  • Use "wixext4" instead of "tools" as the root folder in ".wixext.nupkg"s, from @robmen, is a bit of NuGet hygiene. NuGet has conventions that control its behavior for typical NuGet packages like those for a managed-code library. WiX v4 uses NuGet packages to deliver extensions like WixUtilExtension, which doesn't exactly fit NuGet norms, so we have some flexibility. For WiX extensions, Rob wants to establish a convention for the directory used to store the extension assembly. For WiX v4, it would get the name wixext4, which has the advantage that future versions of WiX could have their own directories which would let one NuGet package support multiple versions of WiX.

  • Remove WixBuild.ExtensionDirectory and WixBuild.ReferencePaths properties and ResolveWixReferences should warn and not include missing references in resolved references, from @robmen, are more of Rob's "sticky notes" -- issues important enough to write down but not so important that it's worth adding to a long, depressing list of bugs. These issues cover behavior that make more sense in the WiX v3 world where WiX and all of its extensions are installed in one per-machine location. They make less in an on-demand, NuGet-ized world, so Rob will be removing them.

  • Reevaluate use of CompareString(LOCALE_INVARIANT to be replaced by CompareStringOrdinal(), from @robmen, is more of a thing to ponder in front of a fireplace while sipping brandy (as you do). WiX has historically supported older version of Windows as long as we could reasonably do so. That meant avoiding Windows API functions introduced in later versions. For WiX v4, we're dropping support for Windows XP (RIP) and Windows Vista (meh). That means we can take advantage of functions introduced in Windows Vista and Windows 7. One of those is CompareStringOrdinal that might work better than the Windows 2000-era CompareString we typically use in native code today.

  • HeatDirectory (v4) task fails, from @barnson, reports what is probably a simple bug in the MSBuild tasks included in the new WixToolset.Heat NuGet package. Everyone knows how much Rob enjoys working on Heat, so he volunteered to fix it.

WiX v4.0-preview.1 status

Once Rob got through reimplementing patching in WiX v4, he took a look at the bugs and the calendar. Based on the relatively low number of remaining issues and the WiX tradition of releasing milestone builds on holidays, Rob suggested to Sean and me that we could probably release WiX v4.0-preview.1 on Halloween. Sean and I agreed and so there it is: We'll work on remaining issues, start filling out the WiX web site for v4, and prepare for the big ol' uploads to nuget.org.

Obviously, Halloween is our target date and sometimes targets are missed. But today, our confidence is high.

What happens after Halloween? It all depends on how many people actively use WiX v4 and how many bugs they discover. We're asking you -- yes, you! -- to get ready to try WiX v4, to convert and test your real-world projects, and tell us about your experiences. The more people who do that, the sooner we can release WiX v4.