Contents
- Digital Signing
- Why should you sign an MSIX package?
- How to sign an MSIX package?
- Where do I get a certificate from?
- How to protect the Certificate with a password
- Certificate Timestamps
- Package Support Framework
- Using the PsfLauncher
- Predefined Fixups
- Applying the PSF
- Config.JSON and Config.XML
- Inspecting Fixups that are in a Package
- Scripting
- MSIX Modification Packages
- Is the MSIX Modification Package the new MST equivalent?
- A deep dive inside the manifest
- How does an MSIX Modification Package work?
- Application Updates
- User Settings and Data Associated with a Package
- Getting Settings and Data Off the Local Profile
Predefined Fixups
In addition to the launcher, the Package Support Framework contains several predefined fixups described below.
ElectronFixup
Electron Apps is used to help apps originally developed as Electron Apps to operate in the MSIX container.
FileRedirectionFixup
The File Redirection is used to solve many file-related issues that could occur.
- The FileRedirectionFixup acts as an aid, allowing the containerized application process to have visibility of files that were captured under certain VFS folders.
The MSIX runtime generally provides an overlay allowing to check the equivalent VFS path inside a package when an application requests a file of a certain path. Unfortunately, there are VFS folders in the package where this does not apply. Originally the AppData, LocalAppData, and CommonAppDatafolders were not mapped on this overlay until Microsoft addedCommonAppData mapping.
The FileRedirectionFixup can provide the additional missing mapping through the use of copy-on-access (described below).
- The FileRedirectionFixup allows the application to write to package files.
MSIX protects the package files, preventing any corruption to the files: a feature sometimes referred to as "immutability". But, applications often need to write to files contained in the package, either to store settings or data.
The FileRedirectionFixup can use copy-on-access to create a user private copy of the file and allow that copy to be written to.
- The FileRedirectionFixup implements a copy-on-access for package files and a redirection for access to the copied area (Advanced Installer handles this automatically).
By default, the files are copied to a package's specific location in the user’s LocalAppData\Packages folder, but this location can be specified using a mapped driver or server share location (specifying the user’s AppData\Roaming folder is not possible due to MSIX limitations).
This allows the application to see areas of the package that are normally hidden, and to make file changes as needed.
Additionally, with the FileRedirectionFixup in use, any future attempt by the application to reference the file, will first detect the copied file as a new mapped layer on top of the packaged one.
DynamicLibraryFixup
Dynamic Library Loading - Used to make sure that the application can find dlls that are in the package.
The MSIX runtime does not implement two of the most important methods for an application installer to specify additional folders to find dll files:
- Modification to the system PATH environment variable.
- AppPaths registration.
The DynamicLibraryFixup allows for the registration of package dlls in the Json based configuration, letting the intercept to cause dll loading to always find the dll in the package.
RegLegacyFixups
RegLegacyFixups is intended to be a place for several types of fixups involving the application registry access. As it is relatively new, we expect that it will be updated over time. Currently, it has two types of fixup rules that may be applied as needed.
- Registry Permissions - Used to modify application registry requests to the permissions allowed under MSIX.
Often an application might open a registry key or item with more permissions than it really needs. Especially for HKCU based items, this could be done in traditional applications, but not under MSIX due to immutability implementations in the MSIXruntime. This intercept rule can target certain types of SAMpermission requests made when accessing the registry.
Assuming the application was asking for permissions it did not need, the Registry Permissions solves the problem. If the app later attempts, in a subsequent call, to use those unavailable permissions on the object, the call will fail. But even so, this might still solve your problem as developers tend to specifically check for permissions when executing such requests, so they handle any eventual errors better.
- Fake Delete - Used to trick the application into thinking that aregistry item or key has been deleted.
We have found some apps that use the registry as a scratch pad for temporary storage, and then try to delete the entries as part of shutting down. As the MSIX runtime does not permit these deletions, using this tool to "lie" to the app could solve the issue.
EnvVarFixup
Environment Variables - Used to turn User Session or System scoped environment variables into Application scoped ones. This affects only processes running inside the container, so it does not help with things such as Path variable changes.
The fixup supports registering the environment variable name and the value inside the JSON configuration, or alternatively, registering the name in the JSON and the value in the package registry. Both methods allow processes inside the container to see the value, and the alternative method supports apps that want to update the value at runtime.