MSIX: Slightly more detail about what might be something huge but probably won’t be

Over on his blog, Rob wrote about his guesses for what the still-somewhat-mysterious MSIX means for Windows deployment. We got some details at the Build conference last week. The two most-detailful were

Here are my key takeaways from these presentations.

MSIX: One package format to rule them all

Appx packages today are Open Packaging Conventions Zip files with a manifest. With the (sometimes painful) magic of XML namespaces, a single manifest can cover many different types of apps: Witness the sometimes-significant differences in the manifests of UWP apps and Desktop Bridge apps. And, of course, Zip files let you easily include different sets of files, like the registry hives in Desktop Bridge app packages.

In MSI terms, the tables that make up the MSI database are represented in special “footprint” files, like AppxManifest.xml and additional well-known files, like Registry.dat. Installed files for an MSI package are typically stored in a .cab file, either embedded or stored next to the .msi file. In Appx, the installed files are stored as normal Zip file entries in the .appx file.

The MSIX Packaging SDK — sometimes named just the “MSIX SDK” — contains MIT-licensed code that implements the Appx packaging APIs to build .appx and .appxbundle packages. If you’ve spent any time building Appx packages, you understand that Microsoft open-sourcing this code is a pretty big deal, if only because the error codes from the API functions are truly terrible and now we can debug the code to better understand error states.

On a slightly more serious note, the MSIX packaging API has several interesting features, like supporting signing and the package “block map,” which is what makes it possible to do differential downloads of package contents.

So that’s all cool but at the end of the day, what we heard about the MSIX format — being cross-platform and available on Windows 7, for example — is essentially saying that Zip files make a good package format because they can contain files (including manifests) and they work everywhere. Well, yes, that’s true but not exactly an earth-shattering pronouncement, is it? A file format is necessary, sure, but what matters is the engine the interprets the contents.

MSIX: One engine to rule them all

MSIX packages, like UWP Appx packages, Desktop Bridge Appx packages, and even MSI packages, are just data. It takes an engine to open a package, read its metadata (manifests or tables and rows), and apply it to the machine.

At Windows Developer Day, MSIX was described as “.appx + MSI.” The mention of “MSI,” combined with repeated mentions of “containers” and tidbits like “Supports all Windows applications” led me almost immediately to assume that MSIX included the use of App-V.

Nine years ago, I joined the App-V team, then in Cambridge (the one in the United States, not the original. One of the big reasons was that I saw a lot of potential in the App-V container model of delivering software. Bringing that capability to ISVs would be a great way to make better installers for everybody. Unfortunately, that didn’t happen while I was there and hasn’t since. But maybe that was about to change…

App-V already supports Win32 features like services that Desktop Bridge does not support (today). App-V already has extensive support for enterprise IT management. App-V has a long history of supporting virtualization of apps that weren’t designed for it.

I’d so thoroughly convinced myself App-V was part of MSIX that I started writing a blog post to parallel Rob’s. Luckily, I didn’t finish it because MSIX is not App-V. There was no mention of App-V at Build except for how it wasn’t going to be deprecated…yet. Naturally, I was disappointed…mostly at having guessed wrong.

Everything discussed at Build points to the engine underlying MSIX on Windows being Desktop Bridge. However, remember that Microsoft has enhanced Desktop Bridge functionality with every release of Windows 10 since the Bridge was introduced in Anniversary Update. So even if today Desktop Bridge doesn’t support some Win32 feature doesn’t mean it never will.

But it also means that MSIX isn’t a revolutionary new engine (or old engine, for that matter) with unexpected power. And unless someone writes such an engine, MSIX isn’t going to be a “thing” on Windows 7. You can build MSIX packages on Windows 7 (and Windows 8.1 — did everyone forget about that one?) but with no runtime engine, they’re just Zip files.

MSIX: Welcome to the evolution

If you found the idea of “.appx + MSI” compelling, well, congratulations, you’re quite the nerd. (Join the club. We have jackets.) The reality, at least as described in Build talks, paints MSIX mostly as a rebranding of Desktop Bridge. That’s not a bad thing but I was expecting more given the buildup.

We’ll likely see more details — maybe we’ll see some exciting ones? — leading up to the next release of Windows 10 later this year.

WiX v3.10.4 and WiX v3.11.1 released

Today, as we bid an indifferent farewell to the 12-month period known as 2017, we shipped WiX v3.10.4 and WiX v3.11.1 to mitigate a vulnerability in Burn. The vulnerability is a little tougher to exploit than the one fixed in WiX v3.10.2; this one requires already-running malicious code that’s specially-crafted to look for bundles that are running with elevated privileges.

As always, we recommend updating to the latest and greatest as soon as possible. Your users won’t thank you but they will yell if you left them vulnerable when you could’ve easily prevented it. The only change is this one small fix, so upgrade with a clear conscience.

Download WiX v3.10.4 here.

Download WiX v3.11.1 here.

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.