My Insight on MSIX Packaging

I’ve been in the application packaging industry for the past 15 years and I’ve seen many different technologies. Therefore, I’d like to share my thoughts on the new MSIX technology and how that would impact application packaging.

UonCloud has been a part of several packaging projects where we had to build MSIX applications and recently I’ve also attended Microsoft MSIX app attach webinar, which led me to my personal conclusion – MSIX is not ready for enterprises and enterprises are not ready for MSIX.

Nowadays every organization is trying to implement the Modern Device Management platform and part of that implementation is to switch to Modern applications. I believe devices are ready, but unfortunately, it seems that applications are not there yet. The easiest way for enterprises to have applications ready, would be to start fresh, yet we know that’s not possible. Enterprises might have to look at some options replacing their existing applications with new products, preferable SaaS solutions (web-based and mobile apps). But that’s easier said than done, since every enterprise has its historical data, hardware to read data, educational materials, backend databases, and so forth. What can we do then to get there and have Modern applications?

We had different successes stories building MSIX applications and I’m not trying to say “don’t do that”, I am simply trying to warn you, shall you decide to go for it: don’t expect miracles and be ready to embrace both options: of success or failure, because not every application that you have will be compatible with MSIX or supported by a vendor. Even with the newest MSIX, you’ll still need packaging, yet this time you will need to have a slightly different approach because you will need someone senior, a very seasoned packaging expert or perhaps more like application analyst with technical packaging skills if you want to have a higher success rate in MSIX.

MSIX doesn’t give you a lot of options to modify the package unlike you were able to do so with regular MSIs, it’s more of a ‘one-time shot’ situation, install à capture à edit (files or registries) à build. If you have a very simple application, that is already an MSI and it doesn’t have any dependencies or other MSIX limitations, then more often than not, it will work. The issues arise when you don’t have MSI or if MSI consists of complex structure and other dependencies (such as Java, .Net, Oracle, drivers, MSP files, etc.) then you most certainly run into a challenge. I’m not saying it’s not doable but it could be hit or miss.

Enough with concerns, let me offer you my vision on a solution, to ensure you have a higher success rate with MSIX, shall you find my suggestion reasonable.

Firstly you have to build a proper MSI package and only then you can try to capture it with the MSIX tool. This will ensure that you know what you are dealing with and you can make the right decision for your application. In order to do that, you will need an experienced packager, who could tell you if it is compatible with MSIX technology or not before you commit to this process.

Here are steps we follow when we build MSIX applications:

1. Vendor delivers MSI or EXE?

• If you have EXE, then you have to search for MSI inside that EXE installer because vendors very often hide multiple MSIs inside a single EXE installer – by doing so you might discover some dependencies, that may not be compatible with MSIX
• If you don’t have MSI, then you will have to capture the installation process with repackaging tool (we use Master Repackager www.masterpackager.com) – this way you can build a working MSI package that could be compatible with MSIX
• Of course, other option is to capture EXE with MSIX tool right from the start, but what if you need to change application settings in XML or INI file, if you captured a proper MSI then you can use it as your project file for MSIX
• If you have MSI, then you can open it with your packaging tools (we use Master Packager www.masterpackager.com) to check what’s inside that respective MSI – so you’ll know what you are dealing with

2. Evaluate and check your MSI package against MSIX limitations

• You can skip this step and build MSIX application from EXE or MSI, however, you might run into the higher probability that you might spend unnecessary time down the road on troubleshooting reasons why it is not working and the worst part is that there is not a lot what you can debug in a first place, as like mentioned, it’s hard to do post-editing after it’s built unlike MSI

3. Build MSIX or stay with MSI

• Now you can come to a conclusion about your MSI package, will it be a good candidate for MSIX or not and if not, you still can use your MSI package and convert it into Win32 app or LOB app

I strongly believe that with this approach you will have a much higher success rate in building MSIX applications and determining the further strategy for publishing and supporting your applications.

Of course, this approach would become obsolete if ISV would start developing applications compatible with MSIX technology or would provide you directly with MSIX application, but not all vendors are prepared to do that yet and many of them are not even around anymore, yet we still use their software.

I certainly know that some of you will not agree with me and that’s great! Please post your comments and let’s discuss.

Written by: Martins Kurtiss