We skipped our last scheduled meeting due mostly to violent illness on my part—betrayed again by discount gas station sushi—so today we had a bigger-than-typical set of issues to triage and issues to discuss.

Issue triage

Adventures with build machines

All of your favorite CI/CD hosted build providers are updating their build machine images to support the latest Visual Studio and Windows versions. However, more than one decided not to include WiX in those images, presumably because Votive for Visual Studio 2022 isn't officially released. However, going back to the days before Git, when it was OK to check in binaries to your source-control system, WiX has been a standalone toolset, requiring only the .NET Framework and standard operating system DLLs. WiX has never required other tools, like Visual Studio, even when it's compatible with such tools.

So, that night on my staycation where I decided to add WiX to the 2022 image for GitHub Actions and Azure DevOps, I decided to remove Votive to simplify the installation of WiX on the image. Days and many bug reports later, I discovered that the build image was using a pre-release version of Votive for Visual Studio 2017, one that contained "redirect targets"—MSBuild targets installed by the Votive VSIX into the Visual Studio tree that load the actual WiX MSBuild targets. We added the redirect targets as a temporary workaround to how MSBuild was changed in Visual Studio 2017 to be local to the Visual Studio installation rather than a global tool as in prior versions.

Later versions of Votive, including the 1.0 release for Visual Studio 2017, dropped the redirect targets, so I had assumed that nobody would be relying on them any longer. That, it turns out, was incorrect. Without the redirect targets, "old-style" .wixproj files created before Visual Studio 2017—and never updated—didn't build.

The team managing the build images reverted my change and after a few days, reimplemented it by adding WiX to the Visual Studio 2022 image and keeping Votive installed for Visual Studio 2017 and Visual Studio 2019. So now old .wixprojs keep building, new .wixprojs build on all versions of MSBuild and Visual Studio, and everyone lived happily ever after.


WiX v4 consumes and supports .NET Framework, .NET Core, and Visual C++. Rob presented a list of versions of those products with their end-of-support dates per Microsoft's product lifecycle. The goal was to decide which versions we should adopt and support in WiX v4.

  • For .NET Framework, we currently build MSBuild tasks for .NET 4.6.1, to support using WiX from the "desktop" (.NET Framework-based) MSBuild. There are some advantages to moving to a later version (focused on .NET Framework's support for .NET Standard) so we decided to build for .NET 4.7.2. This affects only building with WiX and typical developer machines already run .NET Framework 4.8.
  • For non-Framework .NET (.NET Core or "just .NET"—thank you, Microsoft naming), WiX v4 currently builds with .NET Core 3.1, which was replaced by .NET 5 and, last month, with .NET 6. .NET Core 3.1 and .NET 6 are long-term support releases but .NET 5 is not; its end of support date is May 2022. We decided to stay with .NET Core 3.1, for the broadest level of support. (Note that an installed version of .NET or .NET Core is only required for the wix command-line tool. The WiX MSBuild tasks support MSBuild both from Visual Studio and from .NET Framework.)
  • For Visual C++, the story is a bit more complicated. WiX includes several static libraries for native C++. In WiX v3, we build libraries for multiple architectures and multiple versions of Visual Studio: x86 and x64 for VS2010, VS2012, VS2013, VS2015, and VS2017. Visual C++ has done a great job lately of supporting backward-compatible libraries, so we haven't needed to build static libraries for Visual Studio 2019 or Visual Studio 2022. Given that we're adding ARM64 to the platform mix, wouldn't it be great if we could build one static library and support VS2015 through VS2022? I volunteered to research that and report back so we can decide what the C++ baseline looks like.