Today's meeting is number 102 and coincidentally the twelfth anniversary of the first open-source release of WiX. Rob's blog post on that momentous occasion is worth a re-read. And remember, the cake is not always a lie.
WiX v3.10.3 update
This week's update on WiX v3.10.3 is that everyone involved was busy the past couple of weeks preparing for and attending Build so there's no progress on the one remaining bug in GDI+ targeted for v3.10.3. That led to a discussion during the Q&A portion of the proceedings about whether we should continue to hold v3.10.3 for a fix or workaround for the GDI+ bug or ship the existing—important!—fixes we already have from Sean and Jacob as v3.10.3 and introduce v3.10.4 for the GDI+ fix/workaround.
There's always work associated with a release so minimizing that is a positive thing and minimizing how often we announce yet-another-security-fix reduces churn as teams take on new builds of WiX. But if a theoretical WiX v3.10.4 was only necessary for those teams using WinForms-based managed bootstrapper applications, we could encourage everybody to pick up v3.10.3 and recommend v3.10.4 only if you need the GDI+ fix.
In the end, we had a new fix from Sean that we took into v3.10.3 and will distribute that for sanity checking over the next several weeks. That gives us time to test the fix and for a GDI+ fix to materialize. We can make the v3.10.3/v3.10.4 decision then.
Issue triage
Installing v3.11 from the bootstrapper doesn't update MSBuild target paths #5246, from @acohenX1, reports a bug in the Wix.CA.targets files used to build managed-code custom actions. Namely that I didn't update them to point to WiX v3.11 paths. Suitably humbled, I assigned this bug to myself for fixing in WiX v3.11.
Burn 3.9.1208.0: Payload is not picked up from package cache - prompts for source instead #5247 comes from @dsed and reports a difference in Burn's behavior during plan and apply phases. Plan, by design, is fast and so does fast checks; doing more expensive checks, like hashing files, is deferred to when the user has already clicked the Install button, approved the UAC consent prompt, and gone off for coffee. We're keeping the bug open in WiX v3.x to see if we can find a happier middle ground.
Silent installation is not started if access to log file is denied or it doesn't exist #5248 is from @de4rmInc and says that when Burn can't write to its log during a silent operation, it just fails. In full UI mode, Burn shows an error message but when running silently, Burn doesn't show UI. And it can't write to the log, obviously. We decided this was essentially a duplicate of another bug in that Burn should have a fallback log location.
Bundle doesn't uninstall a permanent package on failed Bundle Install, but deletes the cache during rollback. #5249, from @rw1017, reports a problem we've seen before in a different guise: When Burn doesn't install a package, it doesn't cache it, but the cache is needed if the bundle is later repaired. Sean added
Cache="always"back in WiX v3.9, which is a decent workaround, though smarter behavior is always something we strive for.Using a image file for a progressbar element in a burn theme file draws wrong border #5250 is a bug from @andershol on support in ThmUtil for custom-drawn progress bars. Per the documentation, the right edge of the progress bar is drawn using the fourth pixel in the supplied bitmap...except it's not. As suddenly drawing the right edge like the documentation says it should be drawn could be an unexpected surprise, we decided to take this bug in WiX v4.
Pull request review
This week's pull request is an enhancement and replacement for Sean's previously-reviewed pull request. While bigger (and scarier in proportion to size), we all agreed the change is a real fix for the bug and that it cleans up things well. So we took this fix into WiX v3.10.3.