Forum Discussion
Appdata roaming and local in package
Does the problem still exist in MSIX Packaging Tool version 1.2019.1220.0?
- Jan 29, 2020
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.
- thomasboettnerJan 30, 2020Copper Contributor
with your PsfTooling I managed to do it, you did a great job!!
- Jan 30, 2020
- thomasboettnerJan 30, 2020Copper Contributor
I ran through the behaviour with W10 1909 and 1.2019.1220.0 yesterday and found that the problem has not been fixed yet.
Do you have the topic on the list, in my opinion, for our service the behaviour would be a showstoper.
- Jan 30, 2020
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.