Back in February I posted this blog post describing changes that I was making to the PSF to improve app compat, along with a note that it might take a bit for Microsoft to integrate the Pull Request.
For those unaware, PSF stands for Package Support Framework, an open source utility that I contribute to for helping traditional Win32 and DotNet applications run inside the MSIX packaging container. This article contains information regarding new contributions.
Today, that work is finally complete in the Microsoft Develop branch. (All changes in the Develop branch only get pulled into the Master branch when Microsoft releases a new NuGet package, which is infrequently). In addition to the original changes that I previously described, a few more things have been squeezed in, by me and by Microsoft.
PsfLauncher target application and scripting references. In your config.json file, you may now make use of two pseudo-environment variables to reference key package locations.
- %MsixPackageRoot% PsfLauncher will dereference this variable from the string using the path to the mounted application. While it might seem that you could construct this yourself using %ProgramFiles% and appending “WindowsApps” and Package Family Name, we must keep in mind that this is not the only place MSIX apps can be mounted. While the executable field of the target application previously had to be a relative reference from this location, you may continue to just use this relative reference or you can use this variable (or any other full path reference). Of more importance is using the variable for command line arguments that required full path reference and/or the Working Directory.
- %MsixWritablePackageRoot% PsfLauncher will dereference this variable using the location that is used by PSF file redirection in the user’s profile. This variable isn’t really useful for the application target, but for the command line arguments or when when writing scripts.
PsfLauncher target with multiple command line arguments. I also added some fixes for applications that have multiple filename references as part of command line arguments, especially with spaces in the path/filenames.
Scripts now run inside the container. Or, maybe I should just say scripts now work as there were numerous issues discovered by folks. Previously scripts always ran outside of the container, in spite of the option to specify where they should run. When Microsoft made this change, they also removed the option to specify whether it runs inside or outside. I’m not sure I like loosing the option, and might lobby it to come back at some point, but right now we have more important work to do. But fortunately the new Pseudo-Variables that I added allow me to craft a solution to most every case for scripts that I am now looking at, even if it does take more effort. For example, since the script doesn’t run with the PSF in place if you need to access and modify a file in the VFS/AppData area of the package your script would have to copy the source using the %MsixPackageRoot%\VFS… path to the %MsixWritablePackageRoot%\VFS… path and then modify it there.
I will soon be releasing a new version of PsfTooling that includes this version of the Psf. I have a whole bunch of other things in store for that release, making it easier and easier for you to include the Psf in your MSIX packages created using the Microsoft MSIX Packaging Tool.
Stay tuned!
