Today's meeting had more issues to triage than typical yet they were all opened by Rob, Sean, or me. Did we do this to punish ourselves? Maybe but mostly because we're encountering issues as we use WiX itself. That's good news for WiX v4's readiness for a wider audience. Soon!

Issue triage

  • bal:SuppressDowngradeFailure should cause wixstdba to not even try to Plan or Apply, from @rseanhall, was reopened a few months ago and after I came back to implement it, ran into questions I wanted to run by the brain trust. The brain trust was, as always, useful, and we decided that we could reasonably rely on the data available to the bootstrapper application after the Detect phase, without waiting for the Plan or Apply phases to tell the user no install is needed. Now it's back on me to do what we decided.

  • WixToolset.Dnc.HostGenerator runs twice during compilation of WPF BA, from @rseanhall, formalizes a thread on the wix-devs mailing list discussing a broken build after a recent .NET SDK update. Sean took a workaround Rob was using locally and plugged it into the build. I volunteered to verify whether the workaround is still necessary after even-more-recent .NET SDK updates.

  • Including remote payloads in a package that is assigned to a container causes cab creation to fail, from @rseanhall, reports that wix.exe crashes with an exception if a package is authored to be included in a container (for example, when compressed into the bundle .exe) but has remote payloads. Going out on a limb, I'm strongly in favor of WiX not crashing, so I volunteered to take this issue and ensure that such a mix of authoring is correctly reported as an error.

  • wix.exe convert ignores commented inner text, from @rseanhall, reports a weakness in the wix convert code that converts inner text to attribute values, specifically that comments in the inner text prevent the conversion. That's probably a simple logic error and easily fixed, but nobody immediately raised their hands to fix it, so it's just hanging out waiting for a volunteer, unassigned (but not unloved).

  • Bundle without BootstrapperApplication fails with message from exception, from @robmen, is a sibling issue to Unhelpful behavior when including multiple BAs, from @rseanhall, already in my bug queue, both of which are probably the same issue with the same fix: There can exactly one bootstrapper application in a bundle. Not zero, not two, just one. I took this issue and will regret that only if one fix isn't sufficient for both issues.

  • WindowsInstallerValidation target runs even when CoreCompile is up to date, from @robmen, is a weakness in the WiX MSBuild targets. MSI validation is one of the slower parts of building MSI packages, so if the MSI wasn't rebuilt, there's no reason to run validation. Rob expects that he'll eventually pick it up, but as he'll be starting work on patching -- the biggest and gnarliest remaining WiX v4 work -- he's intentionally not picking up any new work. We're happy to cooperate for his overall mental health. (At least until patching is done.)

  • Build exception when Bundle has SoftwareTag but chained MSI does not, from @robmen, is a bug Rob discovered while building a bundle (which happens to be a bundle for some of the "additional" tools in WiX that aren't easily obtained from a NuGet package). Then he fixed it during his coding livestream this week.

  • Burn retries bad MSI installation folder 4x before giving up, despite pressing cancel, from @robmen, another bug from Rob's foray into building a bundle, reveals that pressing the Cancel button on an error message didn't immediately cancel the MSI package. Instead, WixStdBA retried the package four times, each giving the same error. I volunteered to investigate if there's a way to get a cancellation request to actually, you know, cancel.

  • The .wixpdb output folder customization has no effect in a .wixproj., from @robmen, is another issue with the WiX MSBuild targets. There's a property that promises to let you specify the directory for .wixpdb files but it breaks its promise and actually does nothing. Rob volunteered to fix, perhaps as a relaxing foray into MSBuild-land to escape the awfulness that is patching.

  • Update wixstdba themes to use INSTALLFOLDER instead of InstallFolder, from @rseanhall, started out as one thing and ended up as another. Today Burn tries to match properties specified on the command line in typical NAME=VALUE syntax to avoid logging the values of matching variables that are marked as hidden (to avoid logging sensitive data that's passed in as variable values). This isn't perfect, as sensitive data can be included in other ways, but is similar to how command-line property values work in MSI packages. After a bit of discussion, we decided that Burn should do a case-insensitive search for potentially-hidden variables. That allows bundles to keep using mixed-case variable names, without forcing the MSI mechanism of using ALL-UPPERCASE names to indicate public variables that can be set from the command line.

  • SoftwareIdentificationTag table should be prefixed, from @barnson, came from a comment Sean made during Rob's livestream. Most custom tables in WiX v4 have a prefix, something we added to make sure that merge modules built with WiX v3 could continue to be used in MSI packages built with WiX v4. As software tags can't be used in merge modules, there's no concern about table schema changes causing compatibility problems, so I ended up declining my own issue.