We skipped last Friday's meeting because both Rob and I weren't going to be conveniently located next to a microphone, though my jury duty ended up being a nonissue. This week we had a quorum on the bench and triaged—for the third meeting in a row—six issues.
Issue triage
Feature 5125 | Burn should have an option to cache packages that aren't needed for install but will be needed for repair is a feature request I opened after running into a problem with an unexpected source-resolution prompt. Burn doesn't normally cache packages it doesn't operate on—though you can override that by setting a package's
Cacheattribute toalways—but that means that if a package is already installed, it won't be cached and a repair operation will then prompt for source to repair that package. A custom bootstrapper application can request a skipped package be cached but it means teaching the BA to understand why the package isn't being installed. We agreed that the engine is in a better place to know the whys and wherefores and that we should let a bundle author specify that packages be cached for repair.Feature 5124 | Firewall extension: Couldn't enable port exception on Windows XP if the exception exists and disabled. reports that the WiX firewall extension (first created back in 2008) doesn't let you enable a disabled exception. That's a perfectly reasonable feature, so we opened this issue in WiX v3.x.
Bug 5080 | Rebuilding with existing CAB cache can err if CABs are locked reported yet another problem with builds failing due to locked files, as from overaggressive virus scanners protecting us from ourselves. In general, I'd like to live in a world where we can turn off real-time virus scanning but, failing that, we should generally have logic to retry i/o on common failures, so we opened this in WiX v4.x.
Feature 5079 | Insecure handling of hidden variable command line parameters requested more secure handling of hidden variables set on the command line. Two problems moved us to reject this feature request: The first is that anyone can read the command line of another process at the same integrity level. The second reason is that Burn doesn't enforce a particular command-line syntax for setting properties. WixStdBA uses a somewhat traditional
name=valueapproach but a custom bootstrapper application could easily usename:valueorswitch valueapproach instead.Bug 4992 | Fails to harvest project outputs if no win32 configuration exists in the solution. is a bug report on Heat.exe for harvesting from projects. The rationale presented in the bug seems reasonable so we accepted the bug in WiX v3.x.
Bug 4943 | bootstrapper UpdateReplace with perUser InstallScope updates incorrectly came back with the confirmation that Jacob's fix for a similar issue in WiX v4.0 would also fix this issue. As Jacob volunteered to fix it in WiX v3.11, that's where we sent this issue.
Issue tracker moving to GitHub
Today's triage was the last using the custom issue tracker at http://wixtoolset.org/. Rob's started the work of migrating issues to the standard GitHub issues tracker and will complete the work over the holidays before our next meeting. When complete, we'll have a repo in the WiX Toolset organization on GitHub specifically for issues (no code, no pull requests) so we have one set of issues for both WiX v3.x and WiX v4.x, plus any other repos we create.
Live pull request review
As discussed at last week's meeting, today we reviewed a pull request during the meeting so you can get a feel of what Rob and I do when pull requests come in. Today's pull request happened to be one that I submitted to enhance ThmUtil, the WiX SDK library that drives WixStdBA themes, and ThmViewer, the very handy tool that lets you view a theme without having to drive it through your own code.
Next meeting
Because Friday next week is Christmas and Friday the following week is New Year's Day, today's meeting was the last for the year. The next meeting will be on Friday, 8-January 2016. Have great holidays and see you next year!