Proposed platform support in WiX v4.0

Update: See the meeting highlights at FireGiant for the video of the discussion.

Given that WiX v4.0 is a major-version release and will have a number of significant changes in the build environment, it’s a great opportunity to think about which versions of Visual Studio and .NET we should support. We’ve kept compatibility high in mind during WiX v3.x but it’s been eight (!) years since WiX v3.0 shipped. (Eight?! Really? Time flies.)

For WiX v4.0, our stakes in the ground are:

Native-code libraries will be built for Visual Studio 2015 and Visual Studio 2017.

Dropping older versions of Visual Studio dramatically simplifies the WiX build environment. A dramatically simplified build environment opens up new possibilities, such as taking advantage of continuous integration services like AppVeyor.

Building WiX will require the latest update to Visual Studio 2017.

See above re: dramatically simplified build environment. The official WiX build uses the latest available Visual Studio version but unofficial developer builds can use versions of Visual Studio as old as 2010. Maintaining that plumbing gets costly, especially as Visual Studio 2017 is harder to detect. I have work in progress to rely on the Visual Studio developer command prompt which lets us avoid a bunch of registry spelunking.

Running the WiX tools will require .NET Framework 4.6.1 or later.

Previously we’d talked about standardizing on .NET Framework 4.5 but requiring 4.6.1 lets us target .NET Standard 2.0, which opens up interesting possibilities for cross-platform WiX tooling. .NET Framework 4.6.1 was published to Windows Update as a recommended update in early 2016, so most machines will have at least 4.6.1 installed.

What about install time?

DTF and managed bootstrapper applications will still support .NET 2.0 (and of course will continue to support .NET 4.X as they do today in WiX v3.11).

The elephant in the room, the crusty, vulnerable elephant in the room, is Windows XP. Windows XP, in case you didn’t know, was a mildly-popular operating system in its day, and though usage dropped dramatically when Microsoft stopped supporting it with new security updates, it hasn’t gone away entirely.

We’ve maintained support for Windows XP with Burn bundles and MSI packages with WiX custom actions. Sometimes there’s a cost associated with supporting XP or in adding functionality that requires a later version of Windows. The cost is generally small but more problematic is that without a sufficient number of eyes watching bundles and packages on XP, it’s easy for us to accidentally write code that works great on even a semi-modern version of Windows but that breaks on Windows XP. That happened before, unfortunately.

We haven’t made a decision or even a decision to propose dropping Windows XP support, but there are those of us who wouldn’t shed a tear if we did. If you have compelling reasons for us to keep supporting Windows XP, please let us know. As always, we’re listening on the wix-devs mailing list and Twitter.

 

Labeling issues in WiX

During our last WiX Online Meeting, I talked myself into volunteering to study how other projects use labels in their issues. Here’s what I came up with:

  • Some repos prefix their labels to sort them into “namespaces,” like resolution and area. Generally prefixes are common in repos with many dozens of labels. WiX doesn’t have that many issue labels so I propose that we don’t need them. Instead, we should just document the labels we use. Now, who can we get to volunteer to write some documentation? Dammit. OK, I’ll write up that documentation.
  • We have some near-duplicate labels, like compiler and candle. We decided in general to consolidate the labels, preferring a form like compiler (candle).
  • We have some probably-too-precise labels, like burn-acquisition. We decided in general to consolidate those labels as well.
  • One technique some repos use is to tag their issues with labels that indicate a swag at the complexity of resolving it. Two we agreed are useful would be wip-required, when we believe a WIP is necessary, and up-for-grabs, to indicate a relatively simple issue that nobody is yet claiming.

WiX v3.11 released

On Cinco de Mayo 2017, we released WiX v3.11. WiX v3.11 RTM is v3.11.0.1701.

You can download the WiX Toolset v3.11 build tools and Visual Studio extensions here.

The primary goal of the WiX v3.11 development cycle was to support Visual Studio 2017. We met that goal, with more than the usual number of challenges, due to the scope of changes in Visual Studio 2017.

In previous versions of WiX v3.x, Votive, the Visual Studio extension for WiX, was part of the WiX installer. Due to Visual Studio 2017’s changes to support multiple instances, WiX v3.11 now comes in two parts:

  • The WiX build tools, MSBuild support, extensions, and SDKs. These are delivered in the WiX v3.11 bundle.
  • The Visual Studio extension, one for each supported version of Visual Studio (2010, 2012, 2013, 2015, and 2017). These are available from the Visual Studio Marketplace.

Plenty of other stuff happened in the WiX v3.11 cycle, too. For details on bug fixes, new features, and other changes, please see the release notes on GitHub.

Rob also wrote about the WiX v3.11 release, if you’d like other words on the topic.

WiX v3.10.3 released

On 4 July 2016, the 240th anniversary of the approval and publication of the United States Declaration of Independence, the Juno spacecraft is scheduled to enter polar orbit around Jupiter and WiX v3.10.3 was released.

WiX v3.10.3 contains fixes for the regressions introduced in WiX v3.10.2 by the “clean room” technique that mitigates against Windows vulnerabilities that affect bundle executables.

Download WiX v3.10.3.

The following bugs were fixed:

Universe willing, WiX v3.10.3 is the final release of the WiX v3.10 series. Up next is WiX v3.11.

Rob also had words on this release.

WiX v3.10.2 released

An unpleasant first: We had to release a security update for the WiX Toolset. Here’s the recipe:

That’s it, really. Bake and serve and suddenly every executable is potentially a carrier for malware.

WiX v3.10.2 contains mitigations for Burn that avoid the vulnerability. If you ship bundles, you really really need to upgrade to v3.10.2 so you can ship safe bundles.

More details about the release are available in the Setup Matters blog post I wrote.

Download WiX v3.10.2 here.