Migrating to MSIX: Limitations, Workarounds and Solutions

Windows Services limitations in MSIX

Services were not supported when MSIX was initially released; yet, by 2020, with the introduction of Windows 10 version 2004, Services were made available.

However, there are still some limitations when it comes to services in MSIX:

• The Services executable path cannot be edited within the MSIX package if you are using MSIX Packaging Tool. You will need to manually edit the Service executable path before converting your installer to ensure that there are no issues with it.
• Services with dependencies outside of the package are not supported.
• Administrative privileges are required to install an MSIX package with Services.

Despite these limitations, Advanced Installer provides a user-friendly solution for adding a Service to your MSIX package. Check out our comprehensive user guide for a step-by-step tutorial on how to add a Service to your MSIX package.

Handling Installers with reboot in MSIX

Depending on the repackaging tool you're using, it may not be possible to reboot an installer. With the MSIX Packaging tool from Microsoft (version 1.2019.701.0) you can capture installations which require a reboot.

If your installation returns a different exit code than 3010 for the reboot, you can define that custom code to the restart exit codes section in the MSIX Packaging tool.

With Advanced Installer this was possible from the beginning of MSIX since we support the repackaging of applications with reboot for a long time.

.NET Dependencies

According to Microsoft's best practices, it is recommended that applications target .NET Framework 4.6.2 or later when creating MSIX packages.

This is because MSIX packages were introduced with Windows 10 version 1607, and at that time, the .NET Framework was included as a default component. By targeting this version or later, you ensure that your application can be easily installed and run on Windows 10 and newer versions.

Now, it doesn’t mean that your application will not work on lower versions of the .NET Framework, but you should first test the application before starting the repackaging session.

.NET Framework takeaways:

1. .NET Framework versions 4.0 - 4.6.1: Applications that target these versions of the .NET Framework are expected to run without issues on 4.6.2 or later.

2. .NET Framework versions 2.0 and 3.5: In our testing, packaged desktop applications that target these versions of the .NET Framework generally work but may exhibit performance issues in some scenarios.

Drivers

If you have an application that contains a driver, this cannot be repackaged to MSIX as it is not supported.

App Data & Registry sharing in MSIX

As a characteristic, MSIX operates within its own container, which is distinct for each application you run. To learn more about how MSIX manages the app data folder, take a look at our article: How does MSIX handle the temp folder?

For instance, when an application needs to write to the app data folder, it is redirected to a unique subfolder for each app:

%localappdata%\packages\PublisherName.AppName_hash\LocalCache\Local. 

This concept also applies to registry keys; whether an app writes to HKCU or HKLM, the registry is placed in a private, per-user, per-app location.

As a result of this behavior, it's evident that two MSIX applications cannot theoretically share the same settings or outputs. However, there are alternative options available:

1. You can disable file and registry redirection. For more details, refer to this article: How does Files Redirection work with.

Be aware that if you plan to publish your app on the Microsoft Store, it may be rejected, as the flags are only intended for very specific cases.

2. You can use shared containers, which we've discussed extensively in this article: MSIX Shared Containers: How to access resources between different applications. Shared Containers offer additional options such as app customization, prerequisite sharing, add-ons for MSIX applications, and more.

The functionality of MSIX Shared Containers is only available in Windows 11.

How to write data to the installation folder in MSIX

We often come across this scenario in MSIX repackaging, where user applications attempt to write data to the installation folder. However, this is not possible with MSIX. The official recommendation from Microsoft for addressing this problem is to use the Package Support Framework (PSF).

For more information regarding managing non-VFS files in MSIX we recommend to have a look over our webinar here.

You can find a comprehensive article on adding PSF to your MSIX package using Microsoft's MSIX Packaging Tool here.

However, if you are looking for a smoother way to deal with MSIX repackaging, Advanced Installer has got you covered.

It not only provides debugging tools but also streamlines the process of adding redirection. The AIStub.exe included by Advanced Installer in every MSIX package takes care of most of the debugging and issues for you, making it a practical and efficient solution.

Environment variables in MSIX packaging

The Environment Variable Edit Dialog allows various operations and behaviors to be applied to an Environment Variable. However, if you are looking to modify the Environment variable on the system, this will not be modified with MSIX. Instead, it will be overwritten only in the MSIX container of your application.

The settings you had for MSI still apply to MSIX, except for one thing. The environment variables from an MSIX package are visible only inside the container of that application and not for other applications installed on the machine.

MSIX offers an alternative solution called AppExecutionAlias which we covered extensively in this article: How to use any type of Environment Variable in MSIX.

Conclusion

MSIX technology has revolutionized software installations and deployments, yet its adoption rate has been slow due to limited initial documentation, workarounds for legacy software, and a lack of workshops and training programs.

Now, you have valuable information on known limitations of MSIX, including Windows Service limitations, .NET dependencies, driver issues, and MSIX container isolation.

If you're planning to migrate to MSIX technology, it's essential to understand the limitations and available solutions. For instance, Advanced Installer can help you add a service to your MSIX package with ease.

Overall, understanding these limitations and solutions will allow for a smoother transition to MSIX technology.