Today was a big day, full of announcements and technical problems with Skype.
May the Fourth be with you
A while back we reported our intention to move the WiX toolset's current home from Outercurve Foundation to .NET Foundation. Today we officially join .NET Foundation. Read more about it from Rob and .NET Foundation Executive Director Martin Woodward.
WiX v3.10.3 update
This week's update on WiX v3.10.3 is that we're coming up on the end of WiX v3.10.3 updates. Having given up on getting a fix from the GDI+ team, Rob cogitated on workarounds we could implement in Burn. Cogitation successful, he implemented such a workaround and, with some advice from Sean, sent out a pull request we reviewed later in the meeting.
In the meantime, another bug that's a candidate for WiX v3.10.3 came in. So we're not releasing WiX v3.10.3 today but we're definitely approaching the end of the journey.
Issue triage
Wix 3.10/3.11 atom feed fails validator due to mismatch in sellf reference url, from @phillHgl, rightly complains that the Atom feed of WiX releases doesn't pass validation as an Atom feed. We took this into the Web milestone to fix.
Burn: Prerequisite bootstrapper application with /norestart option gets stuck in an infinite installation loop, from @dsed, reports that when you run a bundle with the
/norestartswitch and a managed BA requires .NET to be installed, a forced restart is ignored and the bundle fails. While running a bundle with full UI and the/norestartswitch is pretty rare, we agreed this was an unpleasant bug and took it in WiX v3.x.Burn should use user UI language for localization instead of formatting language, from @jozefizso, is mostly a duplicate of another bug with a pull request destined for WiX v3.11. We kept this bug for the additional suggestion of providing Burn variables for both flavors of language id.
Heat fails without MSBuild tools 12.0 (2013), from @ulabs-sgiroux, is also mostly a duplicate of an older bug. Luckily, Sean, who fixed the older bug spotted this one and responded with detail.
Wix Installer Adding UI, from @elioYakidoo, is a bug in WiX v4.0 and was quickly pounced upon by Rob.
Install the SDK files also if only VisualStudio tools are installed, from @ulrichard, requests support for the WiX native SDK on machines that have the new Visual C++ Build Tools bundle installed. I took the issue and submitted a pull request for WiX v3.11.
Layout to custom directory doesn't copy bundle payload, from @res2k, is the WiX v3.10.3 candidate bug I mentioned before. With a compressed bundle that also has downloaded payloads (like the .NET redistributable), running
/layoutlays out the downloaded payload but copies the clean room bundle, which doesn't have the attached container from the original bundle. This is a serious regression in WiX v3.10.2 so we'll hold WiX v3.10.3 for a fix. Luckily, @res2k also provided a pull request with a fix. Now that we have the automated CLA process with .NET Foundation, we can review and merge this PR quickly.IISWiXExtension IISMAJORVERSION stores #10 for IIS 10 which makes comparisons impossible without a custom action, from @BenOSIsoft, points out that Windows Installer's insistence on supporting only string comparisons means that it's not possible to use MSI conditional expressions to detect that IIS v10 is greater than IIS v7.5. Burn's expression engine is a lot smarter and handles both numeric and version comparisons. Unfortunately, the Burn expression engine and its registry and file searches are available in bundles, not MSI packages. Though that's just code—Burn expressions and searches could be implemented as custom actions. Anyone want to sign up?
NetFx pre-requ installer window does not show all translated text, from @WacomKev, demonstrated with pictures that the pre-req mode in WixStdBA has strings that are too long for their controls. Ah, the brevity of English! Luckily, with humble thanks to me, it's easy to change UI to adapt to longer strings so we took this bug in WiX v3.x.
Referencing PayloadGroup in BA and a package results in Burn failing to initialize, from @rseanhall, reports that payloads that are referenced in both the bootstrapper application and a package in the chain causes a failure at runtime. This is caused by an implementation detail in how payloads are managed. We took this in WiX v3.x.
Directory search in registry, from @EMostafaAli, reports a problem using the MSI
AppSearchfunctionality to find directories from the registry. As WiX can't influence the standard functionality, we resolved the bug as external.Using MergeModules can create invalid .wixpdbs, from @robmen, is an obscure bug, as one might expect Rob to find. As it doesn't result in visible failure and the fix is trivial, we took the bug in WiX v3.11.
[Feature Request] Add support for failure actions flag to 'ServiceConfig Element (Util Extension)', from @emptyVoid, is a request to support a feature of service configuration in Windows Vista and later. We took this in WiX v4.x.
Pull request review
Today's pull request is Workaround GDI+ security vulnerability addresses the GDI+ bug that's been plaguing WiX v3.10.3 for a while now. Essentially Rob's change is to skip the call to SetDefaultDllDirectories when the bundle is already in a secure location (such as the clean room or the package cache). That keeps GDI+ happy which keeps WinForms-based bootstrapper applications happy.