Normally we do new-issue triage first, then do review of issues pending for our next release. Today, Rob reversed the order and it took me a good 20 minutes to get over it. Or did I? Either way, we talked about it all. Read on for a glimpse at the fun.

WiX Online Meeting 304 Highlights
WiX v7 checkin
WiX v7.0.0-rc.1 shipped almost on schedule on 6-Feb. It was a day late because, naturally, signing the release packages was broken. I won’t directly blame Azure…but it was Azure. With lots of printf-style debugging of the build—CI YAML is a punishment for sins in our collective past lives—Rob got it working.
Rob has a grand total of three issues remaining in WiX v7. They’re all documentation issues. I have four documentation issues as well, plus a number of issues I opened to explicitly list the work left to do in the configurable-scope bundles feature:
- Bundles need to store scope when installing and restore it for maintenance and ScopeLock:tm: to prevent scope from changing during upgrade exist to ensure users can’t accidentally change the scope of a bundle during repair or upgrade.
- Implement configurability in WixStdBA and Add scope selection to (select?) WixStdBA themes ensure that configurable-scope bundles are supported by WixStdBA and its themes.
- Handle configurable-scope BundlePackages was a bit of discovered work: Bundles can include other bundles in their chains, so we need to handle configurable-scope
BundlePackages, even in a fixed-scope parent bundle.
There are a couple of smaller issues and my set of documentation additions for configurable-scope bundles, all of which I’m feeling confident will be in well before we ship v7.0.0-rc.2 on 5-March and WiX v7.0.0-rtm on 6-April.
Other, non-WiX-v7, issue triage
-
wix convertdoesn’t handle out-of-proc BA authoring changes, from @barnson, suggests that the WiX authoring needed to upgrade from WiX v4-era bootstrapper applications to WiX v5 and later out-of-process bootstrapper applications. This might be controversial but I’m going to come out in favor of making stuff easier. So this issue isup for grabsfor an enterprising soul to investigate. -
Patch creation allows duplicate DiskId’s in the Media table, from @ListechAu, reports that a package and a patch can have overlapping disk ids, which means the patch won’t work. Rob volunteered to look at this in a future version of WiX.
-
Introduce RedirectionGuard to Burn, from @robmen, noted the RedirectionGuard mitigation that Microsoft added to Windows should be used by Burn when available. Rob agreed and has already implemented it in WiX v7.0.0-rc.1.
-
Exposing code to extract bundles as a service in WixToolsetServiceProvider, from @cerebro-alexiel, comes in response to an old request for a way to “unzip” bundles. Burn’s support for “layout” is similar but different in that it’s used to get downloaded packages and otherwise ignores packages compressed into the bundle. We decided that wasn’t important enough to live in the Burn engine itself but would entertain ways for bootstrapper applications to offer that feature on their own. This issue proposes one way of doing that. It correctly points out that it’s a fairly heavyweight solution because bundle extraction would bring in a fair bit of WiX code, including the hassle of the platform-specific native executable wixnative.exe. I added a comment that a lighter-weight solution might be to instead wrap the native code that Burn itself uses to extract packages.
-
Upgrade to OSMF EULA v1.1, from @robmen, updates the Open Source Maintenance Fee EULA to the latest release. This version has a new minimum amount of revenue before the OSMF applies. That means if you’re more tinkering than selling, you can use WiX without the fee. There are no other changes in the EULA.
-
CoreCompile MSBuild target - support per-culture BindVariables, from @thomasrea0113, requests the ability to provide culture-specific bind-time variables, specifically to support culture-specific licenses in WixUI dialog sets. Rob wants to tackle that problem more generally and I’d suggest that the WixUI portion is really something we should deal with in WixUI. (The use of bind-time variables was a consequence of needing some way to smuggle a file name into the .wixlib portion of WixUI. I haven’t thought through the work needed but we should be able to take advantage of the compiler extension in WixToolset.UI.wixext to support culture-specific licenses.)