The Package Support Framework (PSF) was originally a Microsoft open-source project to help Win32/DotNet applications run when inside an MSIX Container. TMurgent has taken up the support for the PSF in our own fork here on GitHub.
In the new release of the PSF we are now including a new component to help solve one of our constant challenges in getting certain existing Windows applications successfully repackaged into MSIX, caused by some unnecessary restrictions that are in the AppXManifest schemas. And that might be stating the situation too mildly; maybe this is more accurate: The structure of the AppXManifest schemas for registering COM was not designed properly from the start, and we need to work-around these limitations. This was one of (the many) feedbacks that I gave to the Microsoft development teams about 6 months prior to the initial release of MSIX when I was working with early versions as an MVP that was never resolved.
The problem was that the way that many software vendors had constructed and registered their COM components for native installation in the registry was just not supported by the AppXManifest schemas. If I were the software vendor for a product and could edit the source code, then I could easily rearrange how the COM is done to make it work. But for IT people looking to package these vendor-supplied apps into MSIX to modernize their systems were out of luck.
There was a second similar limitation involving multiple shell verb commands (like right click “Edit” on a file type) that we didn’t see too often but limited the functionality of certain apps where we had to choose only one verb to support.
The August 2024 release of the PSF (v2024.08.05) includes a new component, PsfFtaCom that overcomes these limitations.
PsfFtaCom is, in essence just a simplified version of the PsfLauncher component. It is used as a launcher in the package to overcome the Shell Verb limitation that kept a filetype from having different verbs pointing to different executables inside the package (like one program to view and a different program to edit).
But we can also use PsfFtaCom as an application entry in the AppXManifest that allows us to gather all of the COM and Shell Extension entries that were tied to different application entries under one application entry to overcome the uniqueness and matching rules of the schema. If Microsoft had just defined these application-level extensions to be package-level extensions, we never would have had these Com/Shell Extension issues.
The documentation on PsfFtaCom, including samples, is available on the GitHub wiki page for the component PsfFtaCom · TimMangan/MSIX-PackageSupportFramework Wiki · GitHub
The release source code and binaries are GitHub – TimMangan/MSIX-PackageSupportFramework.
PS: This new PSF version, and use of this new component will be fully integrated in the 5.0 version of TMEditX shortly.
