Why software vendors should care about MSIX, and an approach to tackle it

Written by Tim Mangan (guest) · August 1st, 2018

For those reading this that don’t know much about MSIX, I am just going to suggest that you do an internet search, but here are a few links which should quickly lead you to the basics. But consider MSIX to be two things: A new delivery format and a new runtime environment for your applications that will, as much as possible, be compatible with your existing code.

Why?

Here are the primary reasons a software development company should like MSIX:

Eventually, MSIX will become the installer format that your customers expect. At some point, we expect that new APIs from Microsoft will start only being available if you use the MSIX runtime. So you are eventually going to need to be on MSIX or become stale. Your application will be protected from interference by changes to the environment, such as operating system updates and, importantly, other applications. More stability leads to happier customers and fewer calls to your customer helpline. Most of your existing code and use of Windows32 and Microsoft.Net API calls should work in the new runtime. Unfortunately, we are not sure how much will work yet because even Microsoft doesn’t seem to know yet. But it should be most of it. Let’s face it. The MSI format is really old and nobody really likes it. If you knew the things that your Enterprise customers do to the installers you deliver to them you would be amazed that anything even works. The new format will eliminate black holes like custom actions from the installation process, making everything transparent – making the job of customizing the install safe again. It will be far easier for customers to update your software in the new format. Gone will be the days that they buy a copy and run it for 10 or 15 years. This means more support and upgrade money pouring into your coffers.

How?

It will be a while before MSIX is ready for production use on a wide range of applications. We will see it roll out in pieces over a period of time measured in years. So you have time to plan things out. But a subset of capabilities should be coming online soon so get this into your planning for the next year.

The Microsoft approach for you today is as follows:

Try packing up your app as a Windows Bridges (aka Centennial) app. Centennial is similar in format and uses a runtime container. To be honest, very few enterprise-class apps will work in the Centennial runtime because the API coverage is so limited. . But here we are really only using it as an intermediate format. Microsoft has a desktop converter app that can create the Centennial format without access to source code, but you really should use the Advanced Installer ability to directly create a Centennial package from your source code from Visual Studio because there are a few new API things like live tiles, background tasks, and notifications you might be interested in adding.

Run a command from the Windows SDK to convert this package to MSIX format. Then you can test the MSIX with whatever runtime is currently available. Right now, that runtime pretty much acts just like the Centennial runtime so there isn’t a lot of value there yet, but we hope to see the early MSIX runtime capabilities sooner rather than later.

Eventually, better tooling will skip the middleman and you’ll be able to build full MSIX packages from your installer tool vendor, so don’t get hung up over how clunky this process is today.

But I have a different approach that I recommend to software vendors right now. It turns out that the MSIX runtime, when completely built in a few years, should act much more like the current App-V runtime when it comes to API compatibility. So an alternative approach that would provide better feedback right away would be:

Create an App-V package of your existing MSI. This can be done today in the App-V Sequencer, App-V AutoSequencer, or using the, Advanced Installer Architect edition.

Test the App-V package. If there are features that don’t work in App-V, they are extremely unlikely to work in MSIX. You can then look at those features for potential replacement early on.

There are likely to be API calls that work in App-V that don’t work in MSIX. Unfortunately, we won’t know what these are until Microsoft declares MSIX complete. But just building an App-V package helps to categorize your API usage in a language that will be easier to express when we get to that point. That means that we will be able to analyze your App-V package and say – “hey, you need to change how you call THAT” rather than “this feature in your app is broken”.

Use this experience to better support your customers already using App-V today. They are going to continue to use App-V for a number of years, so support them right.

Microsoft has promised a converter to take App-V packages and turn them into MSIX, so your efforts are not wasted. But eventually, you will use MSIX installer build utilities from folks like Advanced Installer to really build your MSIX packages.

Conclusion

Software vendors need to pay attention to what Microsoft is doing here. It doesn’t need to affect what you ship in the next year, but a small skunk-works project now should help you to plan out the work this will cause you eventually.