MSIX Research
Subcategories
These two papers are an older look at comparising the performance of apps built natively for .Net Framework, as a UWP application, or as a MSIX application.
Read more: Performance Comparison of WIn32/.Net Framework/Appx
![]() |
InstalledLocationVirtualization is the next big improvement to MSIX. Although overlapping functionally with the PSF, the ILV is not a full replacement for the PSF’s FileRedirectionFixup or MFRFixup, as these will also be needed in a majority of repackaged apps. I expect a small number of apps may have conflict when used together right now, but over time, the PSF’s MFRFixup should become “ILV Aware” as we find and fix edge-cases where conflict occurs from using both techniques. |
This paper is the result of research into this rather under-documented feature. It uncovers how the feature works, and what impacts it has on packages. The paper also relates this information to that of the Package Support Framework and discusses the advantages, and possible risks, of using both together.
The white paper also discusses the tools and techniques used in the research, which may be helpful for others looking to investigate how other kernel filter drivers operate..
This is a research paper uncovering the performance of .Net Framework apps when tested natively versus MSIX (with and without the PSF).
Read more: MSIX Performance of .Net Framework Apps versus MSIX/PSF
Windows Firewall and MSIX Research
Information on detecting, and either removing or getting local filewall rules supported as part of your MSIX packages.
![]() |
The Problem:Sometimes installers for Windows applications add rules into the local Windows Firewall configuration. When repackaging these applications, consideration must be made as to if those rules should travel with the package and be implemented in the end-user configuration of the local firewall, or if they should be excluded, and dealt with by policy. The Microsoft MSIX Packaging Tool accidentally excludes these during the capture, resulting in packagers not being aware when an application expected the support. The Solution:Using new cmdlets added to our PassiveInstall powershell module in the wrapper script used to custom install the application during repackaging, we can force the rules to be captured. The MSIX Packaging tool will now have the registry entries, but not make use of them in the new AppXManifest schema extensions. But this makes them application request visible to our TMEditX software. Based on TMEditX policy, or manual selection, you can choose to add the necessary entries into the AppXManifest (with a push of a button). Even if you leave them out of the AppXManifest, it still highlights what rules were desired by the application and you can work with the security team to get them implemented in policy. |
Flexible Virtualization: File System Write Virtualization
Information on punching holes in the virtualization of your MSIX package to allow certain files to not be redirected.
![]() |
The Problem:Applications running inside an MSIX container will automatically redirect file writes intended for the user profile. Certain locations, like the temp folder or the user's documents folder are excluded by the PSF, but AppData/Roaming cannot be. Sometimes you need that file to not be redirected so that it is accessible to other applications. The Solution:Using new schema extensions that Microsoft added to the AppXManifest, we can now add controls to turn off certain specific locations for this virtualization redirection. Learn all about it in this research paper. |










