The Microsoft MSIX Package Support Framework (PSF) is an open source project that enables more “traditional” Win32 and Dot Net applications to be repackaged into MSIX.
As an active contributer to the GitHub project, I have added more functionality to the fixups that are available. Additionally, Microsoft has added new functionality as well. Here, I will write about the changes since my last report in February.
Microsoft Changes.
Microsoft added the ability to add scripts to the MSIX package this summer. This support is available from the PsfLauncher and does not require additional fixups.
The scripts are not available as “installation scripts”, but only triggered when the user starts or ends the application runtime. But there is a parameter to only run the script the first time the user runs the application, so it can be configured as a sort of delayed installation script.
The scripts must be written in PowerShell, as you simply specify a PS1 file. You can use existing script languages, but you’ll need to launch them from a PS1 file to use them here. You can also specify if the script runs inside or outside of the MSIX container.
In other news, Microsoft now builds a version of the PSF for you, making it available as a NuGet package. While this is really intended for developers wanting to include the Psf in their released MSIX packages, we have learned from Microsoft that the NuGet package is a glorified Zip file. So it could be possible to obtain the Nuget package, rename the file to a .Zip extension, and extract out the needed binaries. I still think it’s easier for you to use my PsfTooling to inject the PSF into your MSIX repackaging projects, but you now have options.
TMurgent Changes.
The changes I added last spring are finally available in the master branch. The primary focus of these changes was to enable the enterprise customer to control the redirection done by the Psf FileRedirectionFixup. As originally implemented, user changes to files could only be redirected by the PSF to the user’s local profile. It adds the following features:
- Expansion of the base/pattern specification pair to add:
- A redirection base folder (replacement target for the redirection to localappdata).
- An exclusion option (used to disable Copy-on-Access for executables and others. Allows the redirection array to specify exclusion patterns in one element, and a wildcard pattern in the next).
- A “read-only” option (used to lock-down a copy of a configuration file by marking the copy read-only).
- Added AppData/Local, AppData/Roaming, and System to the KnownID list.
- Added a few more common folders seen in App-V packages converted to MSIX using the MPT
- Added special code to perform the missing Copy-on-Access from the package VFS AppData/Roaming & Local & other locations.
With these changes, it is possible to run packages that contain settings and data in all of the file areas that older applications might put them, to allow updates to those files as appropriate, and to control the redirection to send the changed files to a home drive to support roaming scenarios such as VDI and RDS, and for desktop replacement strategies without a loss of settings and data.
Additionally, a number of changes were implemented to improve usability of the PSF. PsfTraceFixup is now more stable, fixing bugs that could cause the app to crash when traced. Additional trace information was added to a number of the API intercepts.
Coming Soon…
There will soon be a new release of the PsfTooling app that includes a pre-built version of the PSF with all of these changes. Keep an eye out for version 3.1 of PsfTooling!
I am also working on my next PSF changes. The idea on this submission will be to allow repackaging into MSIX using the PSF without having to specify the installation folder to place the config.json and PSF dlls in the root folder.
