MSIX & user settings

[michalkala123]

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?

[#2 · Accepted solution]

@michalkala123 

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

[#3]

@michalkala123 

This article contains more details that complement John's excellent summary:

https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes#registry

[#4]

@John Vintzel 

1. How is it possible to install the MSIX package with the snapshot user settings.
2. What is the best practice, to deploy the user settings within a MSIX package.

thx Thomas

[#5]

@thomasboettner 

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.

John.

[#6]

@John Vintzel 

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?

Thomas

[#7]

@John Vintzel 

Do you know what else I could do?

[#8]

@thomasboettner 

What version of the MSIX Packaging Tool are you using and what setting did not persist?  Can you file a feedback hub item and direct message me the link?  attach the MSIX to the feedback hub item if possible.

[#9]

@John Vintzel 

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?

[#10]

@thomasboettner 

Sorry for the delay.  @ShakersMSFT on our team is looking into the issue.

[#11]

@John Vintzel @ShakersMSFT 

it looks like that's the reason for the behavior:

https://techcommunity.microsoft.com/t5/msix-deployment/appdata-roaming-and-local-in-package/m-p/1137...

[#12]

@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:

http://packageology.com/2019/01/fixing-vlcs-msi-package/ 

The tool also has a few bugs btw that means you need to follow a very specific workflow to obtain the desired results:

1. Create and set install folder to C:\Program Files\VLC
2. Start monitoring
3. Launch PsfTooling first so it detects the correct folder
4. Install modified VLC MSI
5. Start shortcut wizard in PsfTooling
6. Uncheck 'Use all VFS path references in Json'
7. Check 'Inject FileRedirectionFixup'
8. THEN press modify button and select shortcut
9. Click 'Apply to proposed change list'
10. Follow similar process for FTAs - ensure to select correct checkboxes BEFORE scanning FTAs
11. Execute changes from Pending Actions tab
12. Stop monitoring in the MSIX Packaging Tool and complete the package

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!

[#13]

@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.  

[#14]

BTW @Tim Mangan, I tried 3.5.0 with VLC during a live customer demo on Monday. Not quite expected results, it created over 200 PsfLaunchers for the FTAs!

[#15]

@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.