App Compatibility Issues in MSIX Containers. And how to fix them - Webinar Summary

We all know that MSIX is an evolving technology - but it is not a fix-all for all the situations we encounter when running Windows applications.

Our colleague Mihai Udrea - Senior Software Engineer at Advanced Installer recently shared his knowledge in our webinar titled: App compatibility issues for MSIX containers. And how to fix them.

Here's a summary of what was discussed.

What is Microsoft's Goal and What Role Does MSIX Play In It?

Although MSIX technology is meant to continuously evolve, we need to recognize and understand Microsoft's main objective. Essentially, Microsoft intends to separate the system state from the application state so that the Windows system maintains its performance over time even with apps added and removed, and the App removal happens without any side effects.

What does this mean for us? That even though we will experience innovations and changes, some things will not change - and we will need to find solutions to eliminate restrictions within the MSIX Containers.

Inside the MSIX Container

If we were to break an MSIX Container into parts, this is what it will include and what we need to know regarding restrictions and app compatibility.

1. Package Files - After installation, package files are heavily locked down and cannot be changed - even if you have the admin credentials. Also, new files can only be added inside the package folders after installation with the "appinstaller" (when installing an update).
2. AppData Redirection - AppData files and folders are written to a new, private, per-user, per-app location. That way the system will know what app configuration files to remove when it uninstalls the application. At runtime, the operating system will present the new per-user, per-app location to the app as the global AppData location.
3. VFS Locations - Windows folders like System, Program Files, etc. are dynamically merged with corresponding directories in the package VFS root folder. This is to support apps that require a runtime DLL to be present in the System folder.
4. Registry - The installation of an MSIX package will NOT change the system registry. However, the application can still use the registry as a settings store, but anything it changes will not be visible outside of its container.

The package registry entries are placed in DAT root files. This serves as the logical equivalent of a Software key in the real registry. The registry entries created at runtime are stored inside DAT files placed in the new AppData location.

What are some of the MSIX Container Restrictions?

After we've identified what's inside the MSIX Container, here are some of the blockers we still need to address when using these containers.

• When an application needs to write inside the package, you need a FileRedirectionFixup to redirect the file to a "per-user, per-app" location.
• If an application needs to Share an AppData file with another app from outside its container, then, you will need a PublicFileFixup to translate the container valid AppData path to that real "per-user, per-app" location.
• If an application loads libraries from other directories, the MSIX Container ignores the AppPaths registry that was used to specify additional library locations. A library folder can be specified using the DynamicLibraryFixup.
• If an application deletes a package registry key, it can cause the application to fail, so the FakeDelete fixups might be needed to allow the application to continue.

What Issues Can Be Solved with PackageSupportFramework?

1. Dynamic essential app configurations (previously done with custom actions) can now be performed using a PowerShell Start script.
2. Another scenario for the PowerShell Start script might be performing the initial app setting based on the items detected on the target machine.

What are some additional PSF Launcher options?

• Working Directory - some apps require the Working Directory to be set to the installation folder. The MSIX Container starts the application using the System folder as Working Directory.
• Parameters - like Shortcut Arguments. if your app needs to pass arguments to its executable when it starts that also can be done through the PSF Launcher.

Identifying Compatibility Issues

You can also use external tools like Process Monitor, but the PackageSupportFramework, the framework that allows fixing these compatibility issues, has a built-in observing tool: the Trace Fixup.

When an application is launched and the Trace fixup is present, all the system function calls are verified -- and the issues get detailed in the log.

The log may contain calls that are not part of the application code (e.g. apps running under the .Net framework).

If you want to get rid of unneeded information, you can change the logging level.

The trace logging level can be configured based on both API category and return value. There are 4 categories: filesystem, registry, processandThread, and dynamicLinkLibrary and by default, it will display only function calls with Unexpected errors.

It can be a struggle to keep the log as noise-free as possible, and for that, the "Unexpected errors" level really helps.

Add Fixups to Solve Compatibility Issues in MSIX Containers

To find compatibility issues for MSIX containers and learn how to fix them by using Advanced Installer SmartPSf, watch the full demo below: