WiX Online Meeting 292 Highlights

Issue triage

• A PendingFileRenameOperations entry is present after Burn exit., from @DS-AndOrz, came back with a pull request that Rob incorporated into another Burn change he made, so both are already present in WiX v6.0-rc.1.

• Increase build parallelization, from @barnson, came back because I trudged through some hairy build work in a feat of heroism and/or avoidance of other work. The performance wins were pretty significant, so I brought this issue back to see if we could get this work into WiX sooner rather than later. It turns out that we can.

• Investigate Fix default feature to respect sections. alternative fixes, from @barnson is my issue to remind myself to talk to Rob about my first attempt to fix the bug I discovered a while back and that was since reported in Default feature attempts to include components defined in unreferenced fragments, from @mediawolf. As a reminder, this issue failed but in light of a user discovering the issue too, Rob and I recommitted to discuss it and potential fixes to see if we can make a fix in WiX v6.

• Harden Burn’s BootstrapperApplication and elevated engine extraction, from @robmen, was the Burn issue I mentioned earlier. A FireGiant customer proposed locking files extracted from a bundle—specifically the bootstrapper application—so they couldn’t be modified or deleted by malware. Surely that’s not possible, launching a process on a locked file, you might declare. Well, it turns out that it is possible…and don’t call me Shirley. So Rob implemented the change. The only downside is that before this change, it was possible for a bootstrapper application to modify any of its own payloads but in WiX v6, those files are locked and attempts to modify now fail. A small price to pay for better security.

• Support harvesting companion files using glob patterns, from @brantburnett, requests that there continue to be a supported way of doing some of the kinds of tweaks that are possible today using Heat and XSL transforms. This particular scenario didn’t meet the bar for something that should be “baked in.” Heat’s code-generation approach supports arbitrary munging of the output; that’s not possible for Files because Files doesn’t generate WiX source code. We’re open to supporting important harvesting scenarios beyond file harvesting in Files but the anything-goes approach isn’t an option.

• Compilation fails due to invalid attribute “Enabled” for element “FirewallException”, from @S1r0hub, turns out to be a doc issue: Firewalls got new features in WiX v5 but one of the new attributes didn’t get tagged as being new to v5. Rob took this issue as a reminder to figure out the process of fixing schema doc bugs when they’re re-integrated into the wix repo.

• wix repo: Repo contains binary artifact CustomActionFail.exe that should be source generated, from @bevanweiss, tracks down a number of binary files that are committed to the wix repo and ought to be generated during the build instead. Rob volunteered to seek them out and replace them.

• Util extension user and group extension tests do not clean up on failure, from @robmen, came from Rob’s frustrations debugging another change. One test failed but left behind detritus that caused later tests to fail too. That’s the kind of thing that causes loud protestations and hair-pulling (if applicable). So Rob fixed the test to always clean up.

• Integration test WixToolsetTest.MsiE2E.UtilExtensionGroupTests.CanChangeCommentOfExistingNonDomainGroup fails intermittently, from @robmen, indicates the need for debugging a particular test. @bevanweiss investigated and was looking for the verbose MSI logs collected during the test run. I thought that happened automatically but at first glance, I saw only logs from the Burn tests. On deeper inspection, the MSI test logs are included, just mixed in with the Burn test logs.

• Is anybody using WiX Toolset v6.0.0-rc.1?, from @Bondarenko1990, came about from the coincidence that WiX v6-rc.1 came out at about the same time Visual Studio 2022 v17.13, which has a breaking change that renders HeatWave unable to build WiX projects without some extra support. The problem isn’t in WiX and is being tracked over in the FireGiant GitHub org as the fine FireGiant folks work on the next HeatWave release.

• There is no class or API like “Unbinder.cs” of Wix3 in Wix5 to extract the files from bundle while bundle is running, from @stonefishy, requests some functionality that was available in WiX v3 to also be available in modern versions of WiX. In WiX v3’s wix.dll, all classes were public because they needed to be public to be consumed by the happy little .exes like candle.exe and light.exe. That they were public was not, in fact, an indication that they were a public API, ready to be consumed like a library. In modern WiX, almost every class is hidden and exposed only as an interface from a service provider. There are no plans to expose a service to allow a bundle to self-extract.

• The application ‘NPS Extension for Azure MFA’ is not adopting the property of 200% text size in Windows., from @msftedad, is another accessibility bug thrust upon poor open-source maintainers who aren’t necessarily experts in accessibility. In this case, there’s a display setting emblazoned with the warning [y]ou shouldn't change these settings unless you need to that lets you adjust text size independently of the scaling setting on a particular monitor. WixStdBA uses the WiX ThmUtil library for its UI, which handles DPI scaling but doesn’t address the text size overrides. We took the issue into the bucket of WixStdBA accessibility issues. If you have accessibility expertise, please comment!

• Package with other dependants is not uninstalled despite BA request to force uninstall it, from @nirbar, reports that the “force-absent” state added in WiX v4 should be more forceful in the case where a package was installed after a bundle that optionally installs that package—complete with accompanying pull request. Reasonable people might agree that’s how “force-absent” should work. (Unreasonable people will be ignored and/or taunted.) We asked for a bit more information about the scenario, but we’re leaning toward agreement.