What Are the Top MSIX Limitations and How to Troubleshoot Them

Introduced in 2018 by Microsoft as a potential replacement for AppX that supports classic applications, MSIX was dubbed as a more advanced, reliable, fail-proof, and universal packaging format. One could think that MSIX was precisely that solution, the Holy Grail of application packaging, that would help you “never regret installing an app.”

However, the more you used MSIX, the more you realized that it does have certain limitations. Luckily, most of them can be resolved. Our application packaging team has gathered the most widespread hard-to-fix MSIX restrictions and the ways you can overcome them.

What is MSIX?

MSIX is a modern application packaging format built on the foundations of existing technologies, such as MSI and AppX, for modern Windows Desktop operating systems applications with the support of desktop, mobile, and other MS devices.

By contrast to MSI and EXE, in MSIX, the file system and registry entries are virtualized, which allows you to abstract the application from the operating system. In other words, it encapsulates a package in a container so that it can either be mounted locally or converted into a virtual disk for use on Windows OS.

Learn more about other package formats.

Benefits of MSIX

MSIX provides tech specialists with reliable, predictable, and safe application deployment methods and scenarios while allowing them to take advantage of constantly updated features and APIs, and offers a wide array of other advantages:

Clean Installation & Uninstallation

A cleaner installation is possible due to the MSIX package’s abstraction layer and virtualized components. In addition, the declarative method with no custom actions in MSIX facilitates the ability of the operating system to track every asset required by your application, thus, allowing the uninstall process to be clean and without side effects.

Disc Space Optimization

MSIX is a perfect format that helps optimize disk space and network, single instance store files on the disk with no second counterparts. When installing another MSIX package with a .dll file that was already installed with an earlier MSIX package, the MSIX technology won’t be using additional space on APPX\MSIX volume to store the duplicate. In its turn, it will link a single instance of this .dll to both packages. However, if the version of .dll changes, it will be unlinked and stored as a separate instance.

Win32 Support

MSIX offers extended Win32 support for those older legacy applications that may be riddled with poor-quality software code.

OS Managed

Operating systems handle all processes involving installing, updating, and removing applications.

App Integrity and Tamper Prevention

With MSIX, using digital signatures makes it possible to avoid installing applications from untrusted sources. As part of its tamper-proofing features, MSIX also records file hashes and detects if a file has been modified after installation.

Overall, all these benefits increase end-user productivity and enhance user experience.

Learn more about the benefits of MSIX format.

MSIX Limitations and Their Fixes

The majority of applications used today on Windows are Win32 apps. These applications were created with the help of time-tested technologies, such as the .NET framework, C++, or C#. However, with the release of Windows 10, Microsoft wished to have a new application architecture that would allow apps to be versatile by running on desktop and mobile OS. As a result, the company introduced the Universal Windows Platform or UWP.

In addition to that, the company wanted to have a better security model: while classic apps were limited to who was running them (the user or administrator), UWP apps would have a special security model with a set of granular capabilities.

In a nutshell, UWP is a platform that allows the creation of apps that work across multiple Windows 10 devices and include not only desktop and mobile but also Xbox and HoloLens. And the platform’s main advantage was that UWP applications don’t need to be rewritten for each type of device.

Win32 applications used to have many system rights, meaning they could easily change something in the system. To restrict the rights and to create an installer specifically for UWP apps, Microsoft was determined to build MSIX that would make an application run in its own “bubble,” preventing it from changing any system files.

While the transition to UWP is gradual, and there are more Win32 applications at the moment, Microsoft has decided to try and pack Win32 apps into MSIX so that you can pack your apps into the new container and have some benefits of MSIX.

There is one downside to this decision. Win32 applications were created with the view to be installed on Windows. They were not created to be packed into MSIX containers to run in their own “bubbles.” Hence, there are some MSIX limitations:

Containerization is not intended for Win32

Win32 is merely not designed to be packaged in a container. Considering that the classical framework of such an application is simply massive, there is no way a developer can foresee all possible operations that the app will execute. The MSIX container just can’t accommodate all possible events.

To fix this issue, Microsoft created the Package Support Framework. The PSF is an open-source project that helps overcome limitations related to your Win32 applications without access to their source code so that they can run in an MSIX containerized environment.

In addition to tools, libraries, and documentation, the Package Support Framework provides runtime fixes (also called fixups) for compatibility issues so that Win32 applications can be packed and distributed as MSIX packages.

Check Microsoft’s step-by-step guide on how to start using the Package Support Framework for Win32 applications so that they can run in MSIX.

Application uses services

An OS provides certain services to programs and users of these programs. For example, such a service can be the CLI (Command Line Interface); Input/Output operations; file system management, etc. Services in the operating system run in the background and have system privileges. Sometimes applications also install those services when the program needs to execute something that requires system privileges. Even though Microsoft does support converting applications with services, the services that have dependencies on other services are just not supported by MSIX. It’s an official limitation recognized by the company.

Advice that can be given here is if you want to repack an application with services into MSIX , you need to check if the services have dependencies. If yes, the application is not the choice for repackaging.

However, if the service is not critical for the application, you can still try to repackage it into MSIX and see what will happen. Thus, you’ll perform an MSIX assessment. Considering that we do not have the application code, the application is a black box to us. Alternatively, you can also try using the Package Support Framework.

Application requires drivers

This is another official MSIX limitation that is hard to fix. Microsoft simply states that MSIX does not support drivers.

Indeed, drivers are officially not supported by the MSIX technology. You can’t pack a driver into MSIX. However, you can compartmentalize the driver and only repack your application into MSIX and deploy the driver into MSI.

Although, as we already know, MSIX has limitations, Microsoft is investing heavily in the technology. We expect that MSIX will become the preferred format for software vendors to deliver applications to customers, taking the place of the more popular MSI in the next decade.