Appdata roaming and local in package

MVP

The application installer adds folders and files to the following folders:

  • the user's AppData\Local
  • AppData\Roaming
  • Common AppData (i.e. c:\ProgramData)

These files are seen in the MSIX package created by the MSIX Packaging Tool (by cracking open the zip compression) as expected under the folders:

  • VFS\Local%20AppData
  • VFS\AppData
  • VFS\Common%20AppData

The Win32 application code uses code such as: 

SHGetFolderPath(NULL, CSIDL_LOCAL_APPDATA, NULL, 0, wstr)

to obtain the location on the target system so as to retrieve the data in a file.  This is done using a CSIDL for each of the mentioned folders. The application displays the retrieved string for the file location so that we can verify what that is and then attempts to read and open the file using CreateFile with Generic_Read access.

 

Under MSIX, the displayed folder paths returned and displayed match the locations for a native install:

  • C:\Users\[username]\AppData\Local
  • C:\Users[username]\AppData\Remote
    C:\ProgramData

 

But the file reads fail for the first two cases but not the third.  This is behavior that I would expect to work in all three cases "out of the box" without the need for PSF shimming.  

 

A Procmon trace shows the system only looking in:

  • C:\Users\[username]\AppData\Local\Packages\[pggref]\LocalCache\Local
  • C:\Users\[username]\AppData\Local\Packages\[pggref]\LocalCache\Roaming
  • C:\Program Files\WindowsApps\[pkgfldr]\VFS\Common AppData

 

 

 

 

 

9 Replies

Hi Tim,

 

We (the Advanced Installer team) noticed this too, we actually tested only the Local and Roaming appdata folders.

 

To solve this and make the converted apps work we've updated Advanced Installer to automatically copy, when the user first launches the app, the files from the appdata VFS folders to the corresponding "Packages" folders.

 

You can try this feature if you are using AI version 15.1 or higher.

 

To easily test it I think you can also import the MSIX package you already have, just rename it to appx first, as we haven't yet updated our import wizards. (Import -> Desktop Bridge Package).

P.S. this auto-fix/shim is included in our free Express edition too. In the linked MSDN article Matteo explains in detail how Advanced Installer applies the fix.

@TIMOTHY MANGAN 

Does the problem still exist in MSIX Packaging Tool version 1.2019.1220.0?

@thomasboettner 

The issue appears to be in the "runtime" of the MSIX and not in how the package was captured.  I have been using changes I made to the PSF FileRedirectionFixup to detect and correct the issue at runtime. I am just starting to work with 1220 this week, but while there are other interesting things in it, I haven't detected any changes to how it captures these files.

 

It may be possible that certain versions of the runtime (at least 1909 but possibly needs November monthly fixes) might now work for a subset of the reported deficiencies. There appears to be no documentation I can find on a change, but I noticed it in December. For now I'm sticking with the Psf/FRF for apps with these issues.  

 

In addition to the PSF/FRF, a solution using the PsfLauncher and a PowerShell script set to "run once" could be used to copy files out the first time the user runs the app.  It would seem more natural to those used to the WIn32 runtime, but has all of the bad properties of a custom action, which MSIX is trying to get away from.  

@TIMOTHY MANGAN 

I ran through the behaviour with W10 1909 and 1.2019.1220.0 yesterday and found that the problem has not been fixed yet.

 

@John Vintzel 

@thomasboettner

 

Ah, a Service would be a different animal indeed. My comments were directed to the portions of the app that are running under the container. 

 

My belief (possibly wrong in which case John should correct) is that while the MSIX package can be used to deliver the Service, the Service itself runs outside of the container, and thus is not able to use any VFS layering, or the PSF fixes, and probably also the containerized registry from the app package. 

 

A full review of containerized package dependencies that the Service has needs to be understood, and I would recommend that you explain those needs to Microsoft.  Non VFS files should be visible just by the Service understanding the different installation folder.  Files in the VFS portion could be copied out to the old native locations via a first run script, although since you are the developer knowing the installation path it might be easier to modify your Service (or service installer) to record where to find the files (which would be a VFS/LocalAppData folder off of the installation root) in a non container registry location. I have no idea what to do about any need of the service to use the app registry in this situation. 

 

But this is the initial attempt at services so maybe there will be room for improvement as Microsoft becomes aware of what the full sets of needs are.   

@TIMOTHY MANGAN 

with your PsfTooling I managed to do it, you did a great job!!

@thomasboettner 

 

Good to hear.  So the issue was with the main app and not the service?

@TIMOTHY MANGAN 

Right, because the VLC player stores its configuration in the appdata\roaming folder, it had no possibility to find the configuration due to the issue Folder Redirection in MSIX.

@thomasboettner Ah! Yes, VLC Player needs the PSF FRF to solve deployment of the config file.  The current version of PsfTooling (3.2) can do that for you.  You may find that the FTAs don't work the way you want, but I'll have that fixed in the next version out.