How To Spot MSIX Limitations Like Master Packager

It’s been more than 2 years since the MSIX technology, a new Windows app package format was introduced by Microsoft. However, it still isn’t mature enough to satisfy the needs of enterprise IT professionals and application developers just yet.

As we follow MSIX development from day one, we know what benefits MSIX brings. We’ve also spotted two problems with this technology that we think everyone isn’t seeing. In this blog post, we want to clearly lay out these two issues and give guidance on how to spot them using Master Packager’s new functionality—Master Repackager MSIX compatibility validation.

Problem 1: MSIX has crucial limitations that MSI doesn’t

Microsoft presents MSIX as the best option of all the installers, but currently—it’s far from that. From the day Microsoft presented this new technology, they interacted with IT professionals and developers all over the world, showcasing an image (see below) with the app package’s best functionalities that support the new MSIX packaging format—setup.exe, MSI, Windows ClickOnce, App-V, and even script.vbs. Spoiler alert—currently it’s not the case.

Diagram showing MSIX at the center, with arrows pointing from older deployment methods like MSI, Setup.exe, App-V, and script.vbs, questioning the full unification of these technologies into MSIX

Watching the MSIX: Inside and Out presentation in Build 2018, everything sounded so nice and bright that we also started to believe—finally, all the IT pro application problems will be solved and we can all switch to MSIX. But the belief was short-lived and got crushed when a gentleman from the audience asked the magic question about enterprise needs when it comes to applications that involve custom actions, drivers, context menus, environment variables, etc. that unfortunately MSIX currently doesn’t fully support.

The MSIX presentations didn’t mention a single word about any MSIX limitations, and there’s very little information from Microsoft about MSIX limitations in general.

Microsoft has documented a few of the limitations under the page name “Know your Installer”. The name is really confusing for us. “MSIX limitations” would be more straightforward. Why are they trying so hard to hide the limitations?

In the beginning, we thought—hey, it’s clear to everyone that there are limitations for MSIX technology and we have to wait until Microsoft tackles them—but that wasn’t the case. Microsoft hasn’t documented a good portion of issues reported in the MSIX Tech Community and other forums. Not everyone has time to follow all the MSIX news on the Internet. In different tech forums, we see people who suggest using repackaging to the MSIX format without mentioning any of the possible showstoppers that MSIX could have.

Problem 2: Knowing if application’s a good candidate for MSIX

How difficult would it be to spot MSIX limitations in your applications? Very. It is very, very difficult and here is why.

A traditional installer consists of files and registries that are laid down in specific Windows OS locations to make the application work. When repackaging applications to the MSI format, repackaging tools like Master Repackager capture all the files and registries and put them in a MSI database using all the best practices.

It’s not the case with MSIX. Even the best repackaging tool with a MSIX build support, including Microsoft’s own MSIX packaging tool, can’t make the application work in the MSIX format due to core MSIX technology limitations.

If you’re a developer, then the MSIX limitations aren’t so tragic for you. You probably know what you’ve developed, so you know what you need. For example, if your application has a context menu wildcard associations that MSIX currently doesn’t support.

It’s a completely different story for IT professionals that want to repackage applications to MSIX.

To understand if an application won’t have any disruptions in MSIX, you need to know the application files and registries inside out, and that’s really hard, especially if the application’s heavy and complex.

Additionally, to make sure the application really works as an MSIX, you need to test all the application functionalities. Yes, all the application functionality. Meaning, clicking and testing all the buttons and scenarios the application can provide.

Without extensive testing and research, you’ll never know which application function can trigger something that MSIX doesn’t support, like writing in the Program Files or the Program Data folder, or having an MS Office add-in, or having a driver, or . . .

Solve problems by validating MSIX limitations with Master Repackager

Before Master Repackager actually builds the MSIX applications, we want to add a functionality that’s a must-have to validate if your application is MSIX compatible.

Validating your current installer for MSIX compatibility can be done in 3 easy steps:

  1. Launch Master Repackager and take the first snapshot on a clean Virtual Machine
    Master Repackager interface capturing the first snapshot.

  2. Install the application you want to convert to MSIX and take the second snapshot
    Master Repackager screen displayed during the system changes phase, asking to check if all complete system modifications are done before proceeding.

  3. Click “Validate MSIX compatibility”
    Master Repackager interface showing the Build screen, with an option to Validate MSIX compatibility
    Master Repackager screen displaying a table that shows whether the package is compatible with MSIX, with clear indicators marking compatibility status.

MSIX Compatibility Validation output:

  • Type: Incompatible; Warning; Information
  • **Description: **Describes found issue in the package
  • **Path: **Path to the source of the issue (available with Master Packager Professional license)
  • **URL: **More information about the issue and possible solution to resolve it
  • Rules can be updated from a remote server without releasing a new Master Packager version to keep up with MSIX development pace and to make sure validation results are relevant

List with all MSIX limitations in one place.

Master Repackager will analyze the captured files and registries and will provide you an output of the application functionality, showing what isn’t supported or needs attention. This will save a ton of time that you’d otherwise spend converting apps to MSIX and then testing manually where in the most cases reverting back to good old MSI without X.

Our final take

We want to spend our time and focus on solving problems for IT professionals. It’s why we developed the Master Packager software—a better and more affordable alternative to work with MSI files so more companies can afford to build the highest quality installers. MSIX limitations is the next IT professional’s problem that the Master Packager team is ready to solve. We want to help IT professionals understand if and when MSIX is a good fit for their managed applications.

Clearly, there are problems with this new, evolving, and promising packaging technology called MSIX. The main hurdle to overcome is to understand if my application will work as expected when converted to MSIX installer. With no documentation of all the MSIX limitations from Microsoft and the missing solution to spot the possible issues, it can take up a real portion of your time.

If Microsoft wants a fast adoption of the MSIX technology within enterprises, they need to do two things—be more transparent and document all the current MSIX limitations and focus to fix the limitations they outlined.

Meanwhile, to understand if your target application can work properly as MSIX, use Master Packager software that will validate and output MSIX limitations. You’ll save your time and money.

Download Master Repackager

Subscribe to our newsletters