Today's meeting was all about triage: six issues, to be precise. Does that mean today's meeting was a quick 20 minutes? Not exactly. As is our wont, we spent a lot of time in a handful of issues, with deep discussion and design. That's one of the great things about real-time communication and we take advantage of it whenever we can.

Issue triage

  • SourceFile attribute behaves differently if populated with a "string" vs "wixVariable\string" is a bug that came back when Sean tested a variant of the original report. Using an absolutely rooted path causes the Burn engine to cache a package to that path. While that's not an exploitable security vulnerability, we agreed that Burn should not allow a bundle to write willy-nilly to anywhere on the file system the bundle author specifies. Sean volunteered to make that fix in WiX v4.0.

  • Can't open solution contains wix project (Visual Studio 2022 Preview)., from @Hominis06, comes back to our attention with the happy news that it's now resolved. The Visual Studio team changed the behavior of exceptions in extensions back to what it was before Visual Studio 2022 17.2 previews and the FireGiant team updated Votive to not use an interface it doesn't implement. Therefore, the bug is double fixed. Rob published a prerelease of the Visual Studio extension with that fix and, if well received, will publish it to the Visual Studio Marketplace.

  • ExePackage ARP Entry, from @rseanhall, is Sean's proposal -- complete with WIP -- to support automating detection and uninstall of ExePackages using the data available in the Uninstall registry key. (This is colloquially known as "ARP," after the Windows XP-era name for the Add/Remove Programs control panel applet.) After some discussion (who, us?!), we decided that a missing or lower version than specified would be detected as "absent" and a higher version would be detected as "obsolete," matching Burn's existing behavior for MSI packages. This feature will allow Burn to be able to uninstall packages that require a separate uninstaller executable to be invoked.

  • Using ShortcutProperty yields warning 1909 on Upgrade after recent Windows 10/11 updates, from @jurijr, asks whether a warning that appears after recent Windows updates is caused by WiX. Short answer: No. WiX is building the tables per the MSI SDK and the same version of WiX is building the MSI packages, so if the behavior changed between versions, that's on Windows.

  • WixToolset.Data.WixVersion Metadata is wrong when invalid and WixVersion parts should not be nullable, both from @rseanhall, are similar and boil down to differences between the VerUtil native code in the DUtil library and WixVersion, the managed class in the WixToolset.Data assembly. These bugs from Sean point out differences between the two. Rob responds that they have different responsibilities: The native code needs to tolerate as many problems as it can when parsing versions because Burn uses it at runtime out in the wild. The managed code, on the other hand, is used while building packages, wants to be as strict as possible. The compromise we reached is that Rob will add a Parse method that returns as much data as it can (unlike the existing TryParse that doesn't). Sean will add to VerUtil the ability to detect when any of the version fields aren't set.