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
Bug in Ukrainian localization, from @Dgroholsky, reports some bad translations in the Ukrainian localization for the WixUI dialog library. Helpfully, corrections are included. I volunteered to look at the localizations, even though I am less than perfectly fluent in Ukrainian.
"error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project." thrown when MSBuildPath parameter was provided for nuget restore, from @echalone, reports a problem with MSBuild that's almost certainly due to the fact that the WiX v3's MSBuild targets don't use the common MSBuild targets. Rob volunteered to take a look.
heat uses deprecated DirectoryRef for standard directories, from @matbech, suggests that Heat in WiX v4 shouldn't use deprecated elements in its output. Well, fine, if you want to be all particular...Rob volunteered to fix this issue.
v4 thmutil Billboard display issues, from @rseanhall, suggests that I made an incomplete change when I was enhancing ThmUtil's support for billboards in themes. In addition to such a scurrilous charge, Sean also suggested that I previously said I would take a look at the problem. As my memory can't be trusted, I just assumed that's true and assigned the bug to myself.
Setup using HeatDirectory task kills Visual Studio 2022, from @henning-krause, points out a problem when using the
HeatDirectorytask in a .wixproj in Visual Studio 2022. As Visual Studio 2022 is now a 64-bit process, the tasks run from a 64-bit MSBuild process.HeatDirectorywraps Heat.exe, which is a 32-bit executable (to support COM registry harvesting). By default, the WiX tasks don't launch the .exes they wrap; instead, to increase performance, the WiX tasks run the .exes as a thread in the task. That's a problem if you try to load a 32-bit executable from a 64-bit thread. The solution is to explicitly run theHeatDirectorytask out of process, using theRunAsSeparateProcessattribute. The WiX targets setRunAsSeparateProcessappropriately automatically for the tasks that they invoke; when you call a WiX task yourself, you have to do that legwork yourself.util:CloseApplication incorrect attribute description , from @Artonus, reports a documentation bug. Rob, who recently livestreamed 90 minutes of his WiX v4 documentation work, volunteered to fix this bug.
.wxl files not parsing if xmlns is missing?, from @robmen, also came pre-assigned to @robmen, so who are we to argue?
Heat Project Harvesting C++ projects doesn't work with Visual Studio 2022/MSBuild 17.0, from @jmairboeck, is another instance of known problems when harvesting project output. Sean volunteered to take a look for possible improvements.
project properties in vs2022 unreadable (dark theme), from @ispysoftware, points out the downside of the ever-popular dark theme: Some UI isn't themeable. That's true with Votive, which was created long before Visual Studio had themes, much less dark ones. However, @drolevar has a workaround to make the old UI look readable even in an otherwise incompatible theme.
Cannot Load a .NET 5.0 Assembly on Build, from @AteCoder, points out that WiX's attempt to harvest metadata from .NET assemblies (when
File/@Assembly=".net"is set) fails when the assembly is built for .NET 5. That's true—but mostly irrelevant because there's almost no reason to identify assemblies as assemblies when using .NET 5 (or .NET 6 or .NET Core or any of the variations of .NET that aren't "classic" .NET Framework). Windows Installer doesn't support non-classic .NET and non-classic .NET doesn't support the concept of a GAC. So unless you're using .NET Framework assemblies, just drop theAssembly,AssemblyApplication, andAssemblyManifestattributes.DifxApp is deprecated, so WixDifxAppExtension should be removed from WiX v4, from @barnson, prompted a bit of a discussion about the cost of legacy support. We decided that for WiX v4, we'd deprecate
WixDifxAppExtensionwith a warning message and remove it in a later version. I volunteered to add that warning.bal.wixext - DncHostFixture.CanLoadTrimmedSCDEarliestCoreMBA() test, from @robmen, started out as a test failure Rob discovered while building with 64-bit MSBuild in Visual Studio 2022 but Sean believes it to be a breaking change in .NET 6. (New versions of Visual Studio tend to bring in a lot of simultaneous low-level changes, don't they?) Sean volunteered to investigate.
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.
Baselines
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
wixcommand-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.