Packaged WPF app returns wrong AppData path when used as argument for a new process

Question

I have a WPF .NET Core 3.1 app packaged as an MSIX app. The app downloads some assets from S3 to the AppData folder and at some point, it starts another process (another app) with one of the arguments being the path to one of the downloaded assets (a Settings.xml file).

I'm facing two problems:

The app sometimes downloads the assets to the "real" AppData path (C:\Users\my_user\AppData\Local\some_created_folder), sometimes to the virtualized path (C:\Users\my_user\AppData\Local\Packages\package_id\LocalCache\Local\some_created_folder). I noticed the latter only recently in 3 different releases (3 consecutive versions): 1st used "real", 2nd used virtualized, 3rd used "real" once again. I'm pretty sure there was no code change that could cause this.
I'm composing the download paths using Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData). When the assets are being downloaded to the virtualized path, the 2nd app is not starting correctly, because the settings file path set as an argument when starting the process is pointing to the "real" path (always!). No exceptions or errors are thrown!

var appData = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
var settingsFilePath = Path.Combine(appData, "Settings", "Settings.xml");

...

var settingsFile = new FileInfo(settingsFilePath);
if (settingsFile.Exists)
{
    var arguments = $"-l \"{settingsFile.FullName}\"";
    var fileInfo = new FileInfo(_options.ExePath);
    var process = new Process
    {
        StartInfo = new ProcessStartInfo
        {
             FileName = fileInfo.FullName,
             WorkingDirectory = fileInfo.DirectoryName ?? string.Empty,
             Arguments = arguments
        }
    };

    if (process.Start())
    {
        process.WaitForInputIdle();
    }

     _logger.LogDebug("Started {name} {arguments}", fileInfo.FullName, arguments);
}
else
{
     throw new FileNotFoundException($"Settings file not found at path '{settingsFile.FullName}'!", Path.GetFileName(settingsFile.Name));
}

I read this, but I don't understand why the app is acting this unpredictable. Or am I missing something? The package manifest file has the EntryPoint="Windows.FullTrustApplication". I'm also aware that UWP Desktop Bridge virtualizes some File System paths, but I'm expecting it to be predictable.

Questions

How can I make sure that my downloaded assets are always on the same path, either the "real" one or the virtualized one?
How can I set the argument for the 2nd app to always point to where the file really exists ("real" vs virtualized)?

When it writes to the non-virtualized folder, it means that the App does not run in Store Context. Are you sometimes testing it locally as in-place registration and sometimes through the regular signed installer? That will explain it. — user173399, Jan 31 '22 at 15:22

Bogdan Mitrache · Answer 1 · 2021-04-23T14:11:51.203

I don't have an anwer yet, but I need more details from you to further investigate this:

Are you sure the files under the "real" appdata folder are not created accidentally by you when debugging the app from VS?

From what I know, packaged apps work with the plain, real AppData resource and path when they open a folder or file already present in that location. If the Appdata folder/files are created from scratch then it should use the virtualized location.

This behavior is useful when migrating from MSI to MSIX, until the user chooses to uninstall the MSI version, the MSI and MSIX variant can be used in parallel both having access to the same AppData files.

Then again, if this is not the first version of your app, and you have previously deployed it as an MSI to your users, you will not be able to know for sure which AppData folder you are working with when running from inside the container.

C:\Users\my_user\AppData\Local\some_created_folder

However, while researching this I found that you can also use Windows.Storage.ApplicationData.Current.LocalFolder.Path to write your appdata. Maybe this would work?

Windows.Storage.ApplicationData.Current.LocalFolder.Path changes the path during normal debug and a test

The second app, is that an EXE from the same MSIX package or another separate application (deployed with its own MSI/MSIX) from the machine? I might be wrong, but if remember correctly the virtualized AppData folder is accessible only inside your app container, so other apps from the machine can't access those files.

If that is the case, you could try saving the data in the CommonApplicationData folder, if this isn't user-specific data.

Related question:

How to allow for editable .Net generated config files with MSIX?

Thanks for the answer. 1. Yes, I am sure that is not the case. I can only reproduce the issue in a PROD environment, where the app is installed from the store. We only have the MSIX version, no MSI before. 2. It is a separate EXE app (no MSIX). — Teslo., Apr 26 '21 at 07:29
As I said and is supported by MSFT in the link below, the AppData folder is not good for sharing info with other apps, since this is private to your app container only: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes Try to use CommonApplicationData folder or another folder that is not virtualized, but first make sure you don't have any files as part of your package that should be installed in CommonApplicationData, otherwise this folder gets virtualized too, as explained in the same article linked above. — Bogdan Mitrache, Apr 27 '21 at 07:32

Mark Ingram · Answer 2 · 2022-01-31T17:08:22.057

I read this, but I don't understand why the app is acting this unpredictable. Or am I missing something? The package manifest file has the EntryPoint="Windows.FullTrustApplication". I'm also aware that UWP Desktop Bridge virtualizes some File System paths, but I'm expecting it to be predictable.

From that link you provided, the details for the reasons why it appears "unpredictable" (note: the behaviour is slightly different before and after Windows 10 1903):

In response to a file open command, the OS will open the file from the per-user, per-package location first. If this location doesn't exist, the OS will attempt to open the file from the real AppData location. If the file is opened from the real AppData location, no virtualization for that file occurs.

And

All newly created files and folders in the user's AppData folder (e.g., C:\Users\user_name\AppData) are written to a private per-user, per-app location but merged at runtime to appear in the real AppData location. ... Modifications to existing files under the user's AppData folder is allowed to provide a higher degree of compatibility and interactivity between applications and the OS. ... State separation also allows packaged desktop applications to pick up where a non-packaged version of the same application left off.

The affected directories are:

Local
Local\Microsoft
Roaming
Roaming\Microsoft
Roaming\Microsoft\Windows\Start Menu\Programs

So, to answer you questions:

How can I make sure that my downloaded assets are always on the same path, either the "real" one or the virtualized one?

To always use the virtualized directories, look at the Windows.Storage.ApplicationData API. The function Local[Cache]Folder will always return the virtualized path.

Failing that, you must make sure that you (or a user) have never written to the non-virtualized AppData locations (e.g. C:\Users\user_name\AppData\MyCompany) as that will always be used in preference to the virtualized location (e.g. C:\Users\user_name\AppData\Local\Packages\MyCompany.MyApp_PublisherId\LocalCache\). That way, you will only ever read and write to the virtualized location.

How can I set the argument for the 2nd app to always point to where the file really exists ("real" vs virtualized)?

The virtualized path to the file is the "real" file.

However, files in this location are only visible to the packaged app itself (see https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization):

Files in the virtualized location are visible only to the app.

One final thing to note. When a user uninstalls an MSIX package, it will delete all of the virtualized AppData that your application wrote.

Packaged WPF app returns wrong AppData path when used as argument for a new process

Questions

2 Answers2

Linked