Today is 2020's last WiX Online Meeting. We return in early January 2021, full of hope in a new year that will return us to a new normal approximating the old normal. To those who celebrate it, Merry Christmas!
Issue triage
Language cleanup, from @barnson, was a phantom bug that somehow eluded our standard WiX Online Meeting query for untriaged issues. It eluded us long enough that I'd opened another issue (Remove "ancient" deprecated language elements) that was mostly a duplicate. However, one bullet point in this issue that wasn't duplicated was the idea of replacing the current set of named elements for standard actions in the
InstallExecuteSequenceelement (and elements for other sequence tables). After a bit of meandering discussion, we came to the conclusion that the effort, even if minimal, didn't really address any serious problems and wasn't worth the effort. However, we're keeping this issue open in case others find deprecated language constructs that we should remove.In-Progress ARP DisplayName and Burn needs to do better at unregistering, from @rseanhall, are the issue-ification of our discussion at our last meeting.
System.OverflowException when calling Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind, from @GnI1991, reports that it's possible to run into an
OverflowExceptionwhen decompiling a bundle, depending on the checksum of the Burn engine (from a custom build of WiX). Sean already fixed this issue in WiX v4 and we decided to fix this as well in WiX v3.14.dialog on zooming the screen content to 400% both the scrollbar appear to view the screen, from @lren, demonstrates that WixUI dialogs don't fit on a low-resolution (for 2020) screen when Windows display scaling is set to a very high value (for a low-resolution-for-2020 monitor). As MSI UI doesn't support reflow or other techniques to automatically resize a dialog.
Remove support for payload verification by Authenticode, from @rseanhall, codifies a years-long plan to switch exclusively to file hashes to verify payloads instead of the current approach where a file's Authenticode signature can allow incorrect payloads to be accepted. We agreed this should be done in advance of WiX v4.0.
Review BOOTSTRAPPER_ACTION_CACHE planning, from @rseanhall, points out that the top-level cache action in Burn can have some unintended consequences (such as leaving payloads in the package cache without registering a bundle to clean them up) and should have some thought given to its design. We agreed and took the issue in WiX v4.0 for investigation and the aforementioned thought.
Unhelpful behavior when including multiple BAs, from @rseanhall, provides one instance of a suboptimal error message that could instead provide some helpful and actionable advice.
Old issue triage
Sean discovered a couple of older issues that were worth re-triaging to see if they were candidates for WiX v4.0:
XmlGetAttribute returns S_FALSE, not E_NOTFOUND, from @wixbot, is an old complaint about how some of the DUtil native SDK functions return S_FALSE, which is a kind of odd not-an-error-but-not-successful return code in COM. It's used in the
XmlGetAttributefunction to indicate that the specified attribute didn't exist, instead of E_NOTFOUND, which the newerXmlGetAttributeExfunction uses in the same state. A particularly brilliant comment points out that S_FALSE is exactly what you want when you don't care whether the attribute exists: A return value that doesn't trigger an error that you need to screen out. We didn't come to firm conclusions, but maybe we should considerXmlGetAttributeExthe replacement forXmlGetAttributeand let the latter live its ignominious S_FALSE-returning life?Calling "rundll32 syssetup,SetupInfObjectInstallAction" triggers addionial wix burn dialog end of installation on 32 bit windows, from @metsma, is a problem we used to see more of, back in the days of Windows XP. In fact, we saw it only in Windows XP, but someone updated the bug earlier this year to say otherwise. The problem occurs due to Burn's use of the
RunOnceregistry key, which is how a bundle resumes following a mid-chain reboot. Until/unless we see the frequency of this problem rise up, we're content to not try to architect a solution that doesn't trigger this problem.