We had a slight-larger-than-average number of issues accumulate during the two weeks since meeting #102. Given that it's evenly divided into the two weeks between meetings, we're concluding that having a slightly-longer-than-average meeting every two weeks is still a good trade.

WiX v3.10.3 update

This week's update on WiX v3.10.3 is that Rob has come to the conclusion that we're not going to be able to rely on the GDI+ team to address their bug in a way that's useful for Burn. So we're off investigating alternatives that we can implement in Burn to compensate for the bug. With luck, a simple and thorough workaround will present itself for inclusion in v3.10.3 and we can skip the need for a v3.10.4. More info to come.

Issue triage

  • Allow DownloadUrl on payloads in the attached container, from @rseanhall, points out that because Burn disallows embedded payloads from having a DownloadUrl attribute, it's difficult to easily switch a bundle from being uncompressed to compressed. I took this opportunity to lament that a lot of how layouts are made, for both bundles and MSI packages, is controlled via authoring rather than project settings. That makes it more difficult than it should to provide multiple layouts, such as DVD, compressed, and Web-only layouts. We took this into WiX v4.0 to treat it as an opportunity to improve how Burn handles acquisition, especially of containers.

  • VS2013 build events and preprocessor variables, from @NPatch, requested support for preprocessor variables in an .wixproj MSBuild project to be allowed where MSBuild properties are supported, or, alternately, to allow Votive to specify MSBuild properties. We declined that, as we couldn't think of another Visual Studio project system that did that.

  • Request to support mathematic operations within Dialog controls, from @joelbudreau, asked for the ability to do (hopefully simple) math within the location and size attributes of controls in MSI UI dialogs. Many of us now prefer bundle UIs over MSI UI, but we agreed this was an interesting feature for WiX v4.0.

  • MSI: Control with @Type="HyperLink" doesn't support @Transparent and @NoPrefix, from @fourpastmidnight, reports that WiX v4.0 currently doesn't support the Transparent and NoPrefix attributes for hyperlink controls. The MSI SDK says that Transparent is supported but doesn't mention NoPrefix. We took this bug in WiX v4.0 to figure out whether both should be supported.

  • [Feature Request] Light.exe: It would be nice to keep the generated MSI database even if validations fail, from @fourpastmidnight, requests that a failing ICE validation not delete the subject MSI package, to help with diagnosing the ICE failure. As WiX v4.0 already does a good job of correctly placing intermediate files in the project's intermediate directory, it should be easy to have WiX v4.0 simple leave behind the MSI when it fails validation.

  • [Feature Request] Improved Syntax Analysis, from @fourpastmidnight, requests that malformed bind-time variable references be detected at compile-time. Currently, syntax errors in preprocessor variable references are detected during preprocessing but strings like !(loc.foo aren't examined by the compiler and are treated as a literal string by the binder. That makes it a manual job to figure out where errors are coming from. We took this in WiX v4.0 to examine as part of an overall overhaul of the preprocessor.

  • preprocessor conditionals executed before command line variables created, from @garymazz, shows that the preprocessor has some rules to follow: The ifndef instruction takes the name of a preprocessor variable, not a $(var.variable) reference.

  • Feature Request: Add service "start parameter" attribute ServiceInstall tag., from @garymazz, requests additional support in service installation but we had to decline it because MSI doesn't support the feature. Currently we have no plans to add custom actions to install services. Plans do change, of course...

  • WiX 3.x installer can be Aero Snapped and maximized but not resized, from @JesperTreetop, demonstrates that the borderless window of the WPF-based WiX bootstrapper application UI resists resizing but can still be Aero-snapped. We took this is WiX v4.0 with the idea that we'll change the UI for a new version. We do have that new logo to show off, after all.

  • MSBUILD fails in VS 2015, but works in VS 2013, from @tomhornyak, appears to have been another instance of a failure caused by the Outlook hyphen/dash.

  • WixVSExtension documentation formating, from @KindDragon, reports another page on wixtoolset.org with horrible table formatting. Luckily, Rob tracked down the root cause of the problem, so we took this into the Web milestone.

  • Burn payloads can have Names that allow escaping cache folder, from me, reports that you can use .. directories in a bundle payload's Name attribute in a way that Burn places the cached payload outside of the payload's correct cache directory. In an extreme—or Xtreme!™—case, it's possible to move a payload to a directory outside the protection of the locked-down permissions of the package cache itself, leaving a payload vulnerable to tampering. My pull requests to disallow such a payload name were this week's pull-request review.

  • Calling "rundll32 syssetup,SetupInfObjectInstallAction" triggers addionial wix burn dialog end of installation on 32 bit windows, from @metsma, is a zombie bug we've seen in the past, back from the dead on a new OS. It seems even current 32-bit builds of Windows can launch the entries in the RunOnce registry key while installing a driver. As Burn uses the RunOnce key to register bundles to handle forced restarts, a second instance of the currently-installing bundle is launched before the first is finished. We took this bug in WiX v4.0 to see if we can find a workaround in the Burn engine. In the meantime, a custom bootstrapper application can detect an in-progress bundle when launched with BOOTSTRAPPER_RESUME_TYPE_ARP resume type. Unfortunately, we can only partially work around the underlying Windows bug; the in-progress installation, if it requires a forced restart, will not resume after the restart.

  • bal:Condition evaluated when executing bundle with /layout, from @joeloff, requests that when a bundle is launched with the /layout switch, launch conditions not be evaluated. As noted, a workaround is to include WixBundleAction=2 in the condition. It's probably safe to assume that launch conditions don't apply when creating a layout, so we took this in WiX v4.0.

Pull request review

I prepared two pull requests, one for WiX v3.11 and WiX v4.0 to fix Burn payloads can have Names that allow escaping cache folder. In the end, we decided to take the change only in WiX 4.0 because of the tiny chance that someone is currently relying on the ability to use relative .. paths in the payload name. I'll get over my disappointment.

Special announcement

In a first since WiX moved from Microsoft to Outercurve Foundation, Rob and I are quite pleased to announce that Sean Hall has accepted the role of WiX committer. As Rob points out, Sean's been doing the work we expect of a committer already, so it's mostly up to Rob and me to notice and appreciate the work. Sean's also the first non-Microsoft employee to be a WiX committer. You'll see Sean in more places where today you see only Rob and me, like merging pull requests. It's thankless work with long hours and no pay, so take a moment to at least mentally thank Sean for his hard work on the WiX toolset.