As noted in our last meeting, this meeting was held three weeks later instead of our usual fortnightly pattern, because Rob was going to be on vacation. Rob was indeed on vacation last Thursday, though some of us continued to slave away without complaint. There are no vacations scheduled in the immediate future, so our next meeting is on 28-April, as per normal schedule.

Issue triage

  • ExePackage exitCode ERROR_SUCCESS_REBOOT_REQUIRED (0xbc2) takes precedence over MsiPackage ERROR_INSTALL_FAILURE (0x643), from @adnanshaheen, points out that Burn and WixStdBA always report ERROR_SUCCESS_REBOOT_REQUIRED when a package requires a reboot, even when that package or any other fails. It turns out that there's also the ERROR_FAIL_REBOOT_REQUIRED error code that would let us include both states in one magical integer. We took the issue for consideration in WiX v4.x.

  • Add ability for bundle author to disable repair for MsiPackage or BundlePackage, from @rseanhall, was a trigger for "let's have an impromptu design discussion as part of triage." Over time, we've discovered that repairing packages that are used to install prerequisites is usually not a great experience for the user, as prerequisites are generally shared and cause reboots, like the Visual C++ runtime packages. As Sean has added the ability to easily include other bundles in a chain, we want to be able to prevent repair on those packages. In the end, we decided that adding a RepairCondition attribute to conditionally enable or disable repair provided the right mix of flexibility and implementation effort. Sean volunteered to do this work in WiX v4.0.

  • Offline Installation of Wix Toolset Visual Studio 2019 Extension failed, from @THE01-MAIYANI, is another example of problems installing VSIXs on machines that aren't connected to the Internet and are therefore unable to download certificates used to the sign the VSIXs. Updating the certificates can be done offline and solves the problem.

  • Can't open solution contains wix project (Visual Studio 2022 Preview)., from @Hominis06, suggests that in Visual Studio preview releases, something has changed that causes Votive to fail in some pretty basic scenarios (including, but not limited to, opening .wixproj projects). I reported to Microsoft that the problem persists in the latest preview released on Tuesday and Microsoft has re-opened their tracking issue. We'll revisit this issue at our next meeting after, one hopes, Microsoft has agreed the problem is on their end.

  • WriteIIS7ConfigChanges: Error 0x80090016: Failed to Commit IIS Config Changes, from @jhaughs, reports a failure using WixIisExtension for IIS on Windows 11. We haven't heard of this problem before, though Windows Server 2022 was also released late last year. Unfortunately, this is the kind of problem that can only be investigated in place, preferably armed with a debugger and eye protection. We took the issue into WiX v4.x for investigation.

  • Allow burn packages to be hidden in the ARP, from @wixbot, came back because of Sean's recent work to add BundlePackage support to more easily install nested bundles. Following a hybrid design discussion model, Sean and Rob started design talk in the issue and got to use the higher-density communication model known as "talking." In the end, we decided that the dependency tracking Burn employs does the right thing by keeping nested bundles installed regardless of whether they're visible in Add/Remove Programs (aka Programs & Features) (aka Apps & Features), even if the user experience might be a little weird: Uninstalling a bundle that was installed both as a nested bundle and a standalone bundle appears to do nothing because the dependency is keeping it on the machine. We also agreed that when a package is marked permanent, it should be visible in ARP by default and that should be the case for both BundlePackage and MsiPackage; that lets users decide what to do when a prerequisite is "left behind" after all the bundles that depend on it are uninstalled.

Archeological issue triage

We also continued and almost-but-not-quite finished our triage of old issues that aren't assigned to a milestone. Here are a few we're keeping around:

  • preprocessor conditionals executed before command line variables created, from @garymazz, reports a difference in how the preprocessor treats ?ifdef? and ?ifndef? preprocessor instructions compared to ?if? when used with preprocessor variables. That difference is documented but the preprocessor could be a bit more helpful in providing an error message. Rob volunteered to take a look in WiX v4.0.

  • Can't resolve CNDL1150 warning with the information given in the warning, from @MarkStega, who was attending today's meeting live, so I'm glad I didn't complain about the content of the issue, was triaged two summers ago but never assigned to a milestone. So we did that: WiX v4.x.

  • RemoveRegistryValue documentation implies it can appear inside a RegistryKey element, from @jdh28, was opened and within a day of triage, had a pull request ready to go. Rob took the issue to make sure it's in WiX v4.0.

  • Could you guys just make better documentation please., from @sixnoteprod, has the word "please" in the title but is otherwise not terribly polite. However, I'll stop editorializing and freely admit that it's not an uncommon complaint. Most of WiX's documentation is reference, at the element and attribute level. There's a decent amount of procedural documentation, mostly in the How To Guides and in the WiX Toolset Tutorial at FireGiant. However, given that MSI is the "do-everything" installer for Windows and that WiX is the build toolset lets you do everything you can with MSI, the number of potential topics is what mathematicians call "very, very big." Deciding on how much and what kind of documentation we focus on is a hard problem, especially when writing is its own discipline, at least as underappreciated as developing good setup packages. Rob kept this issue open for further thought.