Our triage today was fairly noncontroversial and went quickly...mostly because we postponed the issue that we didn't finish last meeting. Don't worry; its time is coming.

WiX v4.0.2

After our last meeting, we said that:

WiX v4.0.2 will instead ship slightly before, during, and/or slightly after our next meeting in two weeks.

After today's meeting, we can confidently say that:

WiX v4.0.2 will instead ship slightly before, during, and/or slightly after our next meeting in two weeks.

We're working with a big, you'd-recognize-it-if-you-heard-the-name FireGiant customer to finalize their move to WiX v4. So we'll slip again rather than take the chance we find a last-minute bug that would require us to ship a WiX v4.0.3. Let's see how things go in two weeks.

Issue triage

  • WIP: WiX v5: Default major upgrade behavior and localized error message, from @barnson, is the WIP we discussed last meeting and needs more talking to resolve. As we need to do some coding in addition to the talking to figure out the right approach, we punted this issue to our next meeting.

  • File Name, Id, and Source confusion, from @computerquip-work, reports observed behavior that doesn't match the documented behavior. It turns out that the documented behavior is just a little bit out of date, so I volunteered to fix the documentation. (The alternative is to make the implementation match the documentation and I encourage developers to seriously investigate that the next time they encounter a bug.)

  • Burn detects the same per-user related bundle twice, once for 32-bit and once for 64-bit, from @barnson, came from my work for a FireGiant customer using per-user bundles. With the change to support 64-bit bundles for x64 and Arm64, bundles now search across both 32-bit and 64-bit registry hives for related bundles. Per-user bundles use the per-user registry hive, which is not also separated into 32-bit and 64-bit hives. (Why are they called hives, rather than just paths or something else? Of course Raymond Chen has the answer). Burn finds two bundles, even though both are the same bundle, and plans to upgrade both. The first upgrade succeeds, removing the cached bundle, and then the second upgrade fails because the cached bundle was just removed. Rob volunteered to get into it when he's neck-deep in Burn.

  • NetFxDotNetCompatibilityCheck custom action badly fragmented, from @barnson, showed up when experimenting with the new DotNetCompatibilityCheck element. Due to the authoring in WixToolset.Netfx.wixext, using any WixToolset.Netfx.wixext custom action brings in all the WixToolset.Netfx.wixext custom actions. That's suboptimal for a couple of reasons, so I adjusted the use of Fragments in WixToolset.Netfx.wixext and the problem went away as if by magic or careful application of science.

  • ICE61 incorrect when version >= 128.0.0, from @jonathan-sansom, reinforces our long-standing desire to replace the Windows Installer SDK ICE validators with even better validators integrated into WiX itself. In this case, we want to replace an ICE because its current implementation is buggy.

  • Failed to bind to CLR error when executing custom actions, from @cubt85iz, reports a problem using managed-code custom actions in what I personally consider favorite Windows feature: The Windows Sandbox. This issue appears to suggest the Windows Sandbox isn't a perfect representation of a Windows OS, which makes me just a tiny bit sad. As it doesn't appear to affect non-Sandbox uses, we put this issue up for grabs.

  • Building native custom action on ARM64 platform fails to find wix header files, from @parvit, reports a problem using Arm64 native code from WiX v3. Arm64 support in WiX v3 is limited, primarily intended for WiX itself, to support the subset of Arm64 support in WiX v3 (compared to the higher/further/faster Arm64 support in WiX v4). As there are no plans for a future WiX v3 release, we didn't take up this issue.

  • ResolveWixReferences always refers to extensions on error, from @barnson, gets extremely picky about an error message. Extreme pickiness is a hallmark of WiX developers and in this case, was rewarded by Rob volunteering to fix the bug instead of having to fix it myself.

  • Oddities in Excluding files via Visual Studio, from @MikeFarrington, is similar to another issue and Rob volunteered to take this issue and investigate whether the similarity is only skin deep.