The Package Support Framework, or PSF, is an open source project hosted by Microsoft up on GitHub. The PSF is useful when building MSIX packages for older Win32 and .Net based applications. It allows you to build in Detours based shims to alter the behavior of the application without needing access to the app source code.
Open to community contributions, the PSF is growing in capabilities. I discussed my initial contribution last week in this article, and then changes I made in my second and third pull requests in this article. In June of 2019 I made another major contribution to the PSF, and additionally Microsoft simultaniously made additional reqested changes to the PSF as well. So what’s new?
Changes I made:
- When using FileRedirectionFixup, you may now specify the location for file based settings and data files that are redirected. Previously, the modified copies were always placed in a folder for the package under a special folder in the user’s local profile. To support roaming users and desktop replacement strategies, you may now specify the redirection base folder. Unfortunately, the MSIX runtime won’t allow this redirection base folder to be in the user’s AppData/Roaming folder (the MSIX runtime will redirect it on us back to the AppData/Local folder) , we can specify either a home drive or UNC share location.
- When using FileRedirectionFixup, you can now make package files in the AppData/Local and AppData/Roaming visible to the app. Due to quirks in the MSIX runtime implementation, the app can’t see files in the package VFS folders for these two locations (it can see all other VFS locations). So the fixup was enhanced to support copy-on-access to any file in these locations (when requested).
- When using FileRedirectionFixup, you can now specify exclusions to the copy-on-access rules. These should be added in the configuration before the more general rule enabling the copy-on-access.
- When using FileRedirectionFixup, you can specify that the copied file is marked read-only. This allows IT to make an AppData/Local or AppData/Roaming file visible but keep the end-user from modifying it. Very useful to prevent changes to legacy forms of application update configuration.
- When using FileRedirectionFixup, Enhanced the list of Known Folders for VFS purposes.. Several folders were missing.
- When using FileRedirectionFixup, added support for applications making file requests using URI syntax, such as “file:\c:\…”.
- When using FileRedirectionFixup, added support for applications making file requests in the form “blob:…”.
Changes that others (Microsoft) made:
- The ability to add limited scripts to a package. The features/limitations on the scripts are summarized as:
- You may now configure PsfLaunch to start a script before starting the application, and/or another script when done.
- Since the scripts are tied to the PsfLaunch configuration in the Applications section of the Json, if you use uniquely named PsfLaunch executables for each shortcut in the package, you can tailor the scripts on a per-shortcut basis.
- When used, these scripts must be PowerShell PS1 files.
- Currently, the PS1 files must be located inside the package rather than on a network share. You must reference the path to the script using a relative path (relative from the package root folder).
- There are a plethera of options, including arguments, waiting, timeouts, hidden or visible windows, running only once, and running side or outside of the container.
- There is a script configuration to stop on error. Although this option is not tied to the start script only, it appears that it doesn’t make any sense to apply it to the end-script (It isn’t like you can tell the application not to exit because the script failed)!Note: Scripting augments (rather than replaces) the ability to launch a second executable using the Monitor configuration that was previously available in the PsfLaunch configuration. While we normally use Monitor only for PsfMonitor, it supports launching any exe, inside or outside of the package when the app starts. Monitor also has its limitations, such as the file must be an exe, it will run inside the container only if the exe is in the package or outside the container if the exe is outside the container.
- A lot of other small pull requests were implemented. Most seem to be general cleanup maintenance of the code, but there are likely to be a few minor enhancements/bug-fixes included. Unfortunately, once the pull request is integrated into the master branch, we loose visibility on what changed and Microsoft doesn’t otherwise document it.
PsfTooling 3.0 will include support for these changes shortly.
