Jul 23 2019 05:43 AM
Jul 23 2019 05:43 AM
I was playing a bit with MSIX packaged applications and how they work with user settings (settings stored in HKCU registry or appdata folder)
I have locally installed software that stores settings in HKCU or appdata, I change some settings on purpose and then uninstall the app - as we know this usually leaves all the user setting on computer.
Then I install MSIX package of the same application to the same client where the user data is left - I launch the application and I can see that all the settings is still applied - which is awesome and makes the transition from legacy installers into MSIX much easier. I tested three different applications - Firefox, VLC player and app called RocLab and it worked in all three cases.
If I change some settings afterwards then it is of course no longer saved into HKCU or appdata - so MSIX app can read the existing data but cannot make changes outside of the container right?
Since I haven't found this documented anywhere I wonder - is this how it is supposed to work?
Jul 23 2019 08:15 AMSolution
By default an app can read from the global registry, which is what an app without a container write to. All MSIX apps share the global registry for reading. This also means group policies function the same whether the app is a legacy installer or MSIX.
An installed MSIX will write to its own virtual registry and app data. This will be deleted when the app is uninstalled or a reset is preformed from the settings app. Other apps will not have access to this information.
John Vintzel (@jvintzel)
PM Lead, MSIX
Aug 05 2019 03:24 AM
This article contains more details that complement John's excellent summary:
Jan 06 2020 11:21 AM
You have options to use group policies to deploy settings or on 1903 and later you can leverage a modification package if that make sense for your scenario. You can also natively configure the default settings when packaging an app.
Jan 07 2020 12:09 AM - edited Jan 14 2020 01:12 AM
I did a VLC Player snapshot with the MSIX Packaging Tool, and during the snapshot, I started the VLC Player and did my configurations. But these configurations are not adopted when the msix application is started.
Did I miss something?
Jan 29 2020 02:33 AM
I have submitted a feedback hub item and sent you a personal message with the link.
Currently it is not possible for me to include configuration files, which are located in the folder C:\Users\%username%\AppData\Roaming\vlc, into the MSIX in such a way that they are used when the MSIX is started.
All files are contained in the MSIX under "Package\VFS\AppData\vlc" but they are not loaded when the application is started.
Is there a way to analyze this better?
Jan 29 2020 11:31 PM
it looks like that's the reason for the behavior:
Feb 07 2020 06:25 AM - edited Feb 07 2020 06:27 AM
@thomasboettner If you want an MSIX package to read from the AppData folder inside the package, you need to use the redirection fixup within the PSF.
This involves replacing all shortcuts and file associations to point to a new stub exe that then loads VLC and injects some wizardry to make it pull a copy of the config file you supplied and copy it to the app's data area if it does not already exist.
Tim Mangan's PsfTooling app can help here, however the current release version does not gracefully handle the file associations VLC puts down. I worked around this by grabbing the MSI build of VLC and editing to remove all shortcuts but the main one, and modifying the file associations to make them simple with no additional parameters. This requires the MSI to be patched first, which you can do via my script:
The tool also has a few bugs btw that means you need to follow a very specific workflow to obtain the desired results:
I will post a full recipe on the blog in due course but am currently busy trying to migrate the site to a new platform!
Mar 11 2020 06:56 AM
@thomasboettner, @Dan Gough PsfTooling 3.5.0 added improved coverage for FTAs, and Vlc should be deployable. We can't fix all FTA issues on all apps because ultimately we depend upon the Microsoft Packaging Tool to format the manifest, so feedback on specific cases remains important so that the MS team can improve the tool.
Microsoft partners with complete repackaging tooling are also an option, and any enterprise looking to repackage a number of applications may be need to use more than one tooling set to be as successful as possible.
Mar 11 2020 07:36 AM
@Dan Gough When the FTA command action uses different command line arguments, a separate copy of the launcher is required as the arguments are tied to the launcher. The tool should be smart enough to handle %1% without duplication. I don't see that many launchers in my package, but I'm using a newer unreleased version of the tool.
When there are not ANY conflicts in arguments, the alternative approach is to not address FTAs in PsfTooling but to manually modify the manifest in the Packaging Tool to add an "execution alias" for the target exe to point to PsfTooling. PsfTooling architecturally can't address the manifest, so that is a manual effort in the MMPT at this time. Third party tooling vendors that generate their own manifest files will likely go this route.