Self-Contained App Crashes When Using ApplicationDataContainer

[anlocnghg]

My app previously used 'framework-dependent' deployment (it installed in an user local app folder and could be distributed via Microsoft Store). However, due to our organization's requirements that only xCopy deployment is allowed, meaning self-contained app. I followed the instruction (Link), everything initially was okay. Only until I started using the ApplicationDataContainer, for example:

private void myButton_Click(object sender, RoutedEventArgs e)
{
    myButton.Content = "Button Clicked";

    // App crashes
    var localSettingContainer = Windows.Storage.ApplicationData.Current.LocalSettings;
}

I know that since the xCopy deployment (self-contained app), there is no user local storage folder for the installed app. I would like to ask what is the best way to walkaround this issue to be able to reuse to ApplicationDataContainer, or any other app settings container API?

Thank you very much!

Below is steps to reproduce the crash:

1. Create a new WinUI3 app
2. Make this app self-contained by editing the project file following this link.
3. Created a variable referencing to Windows.Storage.ApplicationData.Current.LocalSettings in a Button Clicked handler, for example:
   var localSettingContainer = Windows.Storage.ApplicationData.Current.LocalSettings;
4. Run and the app crashes when the button clicked

[anovik]

Any solution to this?

[DarranRowe]

Use the desktop AppData directories.
The ApplicationData runtime class provides the location of the package data directories, which usually ends up being %LOCALAPPDATA%\Packages\<insert package family name here>. If your application don't have a package then this directory doesn't exist, so any attempt to access it will fail. What this means is that the call to ApplicationData.Current will fail with the error code of 0x80073d54 because the process has no package identity.
For unpackaged desktop applications (which include WinUI 3 when not using a package), you can just use SHGetKnownFolderPath or other such functionality, such as Windows.Storage.UserDataPaths, to get the path to your local AppData directory and set it up to your liking. Since the local AppData directory is a shared resource, this normally means creating a directory here for your own application.

[DrusTheAxe]

Are you an unpackaged app? Windows.Storage.ApplicationData.Current only works if you're a packaged app as it looks up the data resources given the current process' package identity.

If you're unpackaged you should use AppData as @DarranRowe suggests. SHGetKnownFolderPath(...FOLDERID_LocalAppData...) is the definitive way to get the per-user local root path for application data. Unpackaged apps typically store data under there in a publisher\application specific subdir, e.g. Fabrikam's Contoso app would create the directory SHGetKnownFolderPath(...FOLDERID_LocalAppData...) + "\Fabrikam\Contoso" as the unpackaged moral equivalent to the packaged Windows.Storage.ApplicationData.Current.LocalFolder

The registry under HKCU\SOFTWARE\company\product is the unpackaged app's moral equivalent to packaged apps' ApplicationData.LocalSettings, e.g. Fabrikam's Contoso app would create the subkey RegCreateKeyEx(HKCU, "SOFTWARE\Fabrikam\Contoso") for its data.

Microsoft.Storage.ApplicationData #2639 has information on the subject you may find helpful (and if that enhancement interests you please share your feedback. Squeaky wheel and all that :-)

[anovik]

@DrusTheAxe It is clear that ApplicationData.Current works only for packaged apps but it seems when you turn packaged app into self-contained, this stops working, is this correct?

Also, may it be so that this functionality works different for windows 10 and windows 11 APIs? For self-contained app ApplicationData.Current worked for me for Win10 but didn't work for Win11. Not sure what can be the reason.

[DrusTheAxe]

seems when you turn packaged app into self-contained, this stops working, is this correct?

Nope. They're orthogonal concerns

• Packaged vs Unpackaged = when the app runs does the process HAVE or LACK package identity?
• MSIX vs Self-Contained = when the app runs does it satisfy its WinAppSDK dependency via the WinAppSDK MSIX packages or via files installed with / part of the app?

ApplicationData.Current is solely related to the former. The .Current property doesn't care how you're referencing WinAppSDK. Or whether you are at all. ApplicationData.Current is a Windows API for all packaged apps, but only packaged apps.

may it be so that this functionality works different for windows 10 and windows 11 APIs?

That won't matter. ApplicationData.Current is a Windows API since Win8.

For self-contained app ApplicationData.Current worked for me for Win10 but didn't work for Win11. Not sure what can be the reason.

Are you sure you ran as a packaged app on Win11? Being self-contained or not won't matter, but having (or lacking) package identity very much will.