Today, in addition to triaging a number of new, incoming issues, we triaged a bunch of existing issues that hadn't been assigned to a milestone. We wanted to see how many should be assigned to WiX v4. We didn't get through all of them and will have to wrap up their triage at our next meeting. Normally that next meeting would be held in two weeks, but as Rob will be on spring break -- presumably his kids' spring break, though I hold out hope it's a FireGiant-wide spring break so I can celebrate First Contact Day with a not-quite-new look back at 70s-style hair and pajama uniforms -- our next meeting is scheduled for three weeks out, 14-April.

Issue triage

  • Patch created using purely WiX does not include changes to XmlFile table, from @nirbar, reports that the default filtering mechanism when building "pure WiX" patches does not correctly include changes made by WiX extensions. We concluded back when we first triaged the issue that a non-trivial design change would be necessary to make that work. That conclusion hasn't changed and as it would be a change in behavior, we took this issue into the v.Next milestone.

  • bal:SuppressDowngradeFailure should cause wixstdba to not even try to Plan or Apply, from @rseanhall, comes back as a refinement to my original fix. Sean thinks that attempting to install a lower version of a bundle when bal:SuppressDowngradeFailure is set should automatically go to the "success" page, much like how it automatically goes to the "failure" page when bal:SuppressDowngradeFailure isn't set. I agree and volunteered to take a look, though it's fairly low on my personal to-do list.

  • util:CloseApplication incorrect attribute description , from @Artonus, is a documentation bug that Rob volunteered to fix as part of his work in this area.

  • CanInstallAndUninstallSimplePerUserBundle_x64_wixstdba Burn integration failing, from @rseanhall, was already in my bug queue but not properly assigned to WiX v4 Preview One project. Now it is and they all lived happily ever after.

  • Dutch translation for UtilExtension for Wix v3 and v4, from @HarmvandenBrand, was a bug report with accompanying pull requests -- and there was much rejoicing! -- that we decided to accept in both WiX v4 and v3.14.

  • sr-Latn-CS should be replaced with sr-Latn-RS, from @Dialecticus, is an example of how localization bugs can come about from geopolitics. We'll replace the sr-Latn-CS localization with sr-Latn-RS in WiX v4 and, for backward compatibility, add sr-Latn-RS in WiX v3.14.

  • Variable name with loc variable stays unresolved, from @rseanhall, says that if you want to use localization variables in naming a bundle Variable -- like <Variable Name="!(loc.BuiltinBurnVariableName)" Value="1" /> -- that weirdness is rewarded by not working. Rob agreed it should work and so volunteered to make it do so.

  • .wixproj support for multi-arch .wixlib, from @rseanhall, wants to be able to do in one .wixproj what you can do today using the wix build command-line approach. WiX v3 also doesn't support multi-architecture .wixlibs from MSBuild, but WiX v4 offering architecture-specific custom actions means it's becoming more important. On the other hand, supporting multiple architectures usually requires a bit of preprocessor magic to ensure unique ids and compiler extension alchemy to choose the right ids. That's a problem we want to tackle in the WiX language itself but MSBuild support for multi-architecture .wixlibs is something that could be added in a WiX v4.x release.

  • Remote payloads should not allow Hash information to be specified with Certificate information, from @rseanhall, is fallout from restoring Authenticode payload verification to Burn. When payloads are validated by hash, Burn uses the hash of the payload as its id in the package cache, to ensure the exact file requested by the bundle is being used. When payloads are validated by Authenticode signature, there isn't an identifier that's as usefully unique as the hash. Our discussion concluded with the CacheId being required when using Authenticode verification, as a primate-level brain is required to choose an appropriate cache id.

  • Accessibility bug - installer - destination folder, from @theJasonHelmick, is another accessibility bug we're tracking among other accessibility bugs in the WixUI dialog library.

  • MsuPackage: wusa.exe /uninstall /kb:# /quiet is deprecated, from @rseanhall, surprises the triage team with the announcement that Windows 10 deprecated the ability to silently uninstall .msu packages. As elevated privileges are required to install and uninstall .msu packages, the stated hand-waving rationale of the deprecation for "security risk" reasons is questionable. (Use your favorite search engine to look for blog posts using the term Raymond Chen airtight hatchway.) However, it means that Burn should probably no longer assume it can uninstall .msu packages. Given that .msu packages are typically used for Windows updates, not being able to uninstall them is probably not a significant loss.