Today's meeting was all about that triage, mostly re-triaging issues for a closer, up-to-date look at those issues. Unfortunately, Rob and Sean disagreed with my opinion on more than one occasion today, even though I'm the one who writes these highlights. Nonetheless, I shall maintain my highest levels of editorial neutrality and fairly report their bad opinions and general poopyheadedness.

Issue triage

  • NetFx.wixext .NET Core packages don't detect newer versions, from @rseanhall, is an issue I brought back to the esteemed triage team for discussion and maybe a skosh of planning. The way we dealt with the .NET Framework redistributable packages doesn't work well for the .NET Core and .NET v5 and v6 redistributable packages. There was some interest last year from Microsoft folks in making the new .NET redistributable packages work well and we decided that Sean would check in with them to see if they're interested in picking up that work again, now that we're closing in on WiX v4 Preview 1.

  • Port WixStdBA "files in use" page to Wix4, from @gvkries, is another issue I wanted to re-triage. As was the custom during the development of WiX v3.x releases, the addition of files-in-use functionality in WixStdBA was opt-in. We don't need to keep it opt-in for WiX v4.0, but I wanted to get the team's opinion about whether we should instead have an opt-out. You can't entirely opt out of files-in-use functionality in an MSI package, so I didn't have strong feelings either way. It turns out, neither did Rob and Sean. I considered all the (lack of) input and took the path of least effort: No opt-out until/unless someone complains.

  • Unable to build after updating to version v3.14.0.4118, from @barnson, is (surprise) another bug to be retriaged. The files that implement ICE validation (somewhat amusingly called CUBEs) need to be updated to handle WiX v3.14 and v4 now supporting ARM64 but, annoyingly, two subsequent updates to the CUBEs have introduced different bugs. One broke validation on merge modules and one broke validation on regular MSI packages. It wasn't my favorite choice, but we decided to mix and match CUBEs to get a set that works, while continuing to hope that Microsoft releases a matched set that fix both bugs (without introducing more).

  • Dependent patch packages are not cleaned from the packagecache during uninstall., from @siasil, reports that uninstalling a patch bundle is leaving its packages behind in the package cache. Sean was able to verify thanks to the provided repro project -- thank you for that! The cause isn't immediately obvious so further investigation is needed. We took the issue into WiX v4.x.

  • Consider not setting WixBundleInstalled and WixBundleAction before Detect and Plan, respectively, from @rseanhall, suggests different handling for two variables that the Burn engine sets during initialization from limited data, command-line values, or defaults. WixBundleInstalled is set from limited registration data but really should be set after the Burn detect phase has run. WixBundleAction is set from the well-known command-line switches (like /uninstall) or the default (also /install) but is then reset to the actual action the user chooses. A custom bootstrapper application can detect the default value without relying on WixBundleAction but thanks to Sean's work to add condition support to ThmUtil, having that default action in a variable is highly useful. So Sean will add a new WixBundleCommandLineAction variable and set WixBundleAction only during planning.

  • heat.exe throws an ConfigurationErrorsException when the '#' symbol is in the path name, from @ericziethen, reports a crash in Heat (well, .NET Framework, via Heat) when using a directory with a # in the name. There's probably nothing we can do to make .NET Framework handle that case and as Heat in WiX v4 doesn't use the old .config file system, it doesn't have this problem.

  • Dark theme, from @rakleed, requests support for system themes in...well, we're not sure where. But we know supporting themes in MSI UI would be infeasible without direct support in the MSI UI engine. On the other hand, bootstrapper applications could, including WixStdBA. It's a neat idea, so we took the issue in WiX v4.x for someone interested in doing that work.