Self-Contained App Crashes When Using ApplicationDataContainer

[anlocnghg]

Discussed in #2618

^{Originally posted by anlocnghg June 13, 2022}
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

[jonwis]

The ApplicationData type needs package identity to know where to store the data. xcopy-deployed apps don't have identity by default. I'm not finding an easy way to construct an ApplicationDataContainer on its own outside of ApplicationData but we'll ask around.

Good feature request, though - "where should I store my data for apps that aren't strictly speaking installed?" I'd suggest something under %localappdata%\temp by default, and we could use cues from the app itself (like the identity in a side-by-side manifest) to put something under %localappdata%\$(publisher)\$(appname) ...

[DrusTheAxe]

I'm not finding a easy way to construct an ApplicationDataContainer on its own outside of ApplicationData

You can strike 'easy'. ApplicationData requires package identity as the data store is created when the package is registered. If you're not packaged then no package registration thus no ApplicationData data store thus ApplicationData[Manager] APIs won't work.

The recommended options:

• Windows.Storage.ApplicationData.Current -- packaged apps (i.e. process has package idenitty) running in AppContainer
• Windows.Storage.ApplicationDataManager.CreateForPackageFamilyName(pkgfamilyname) -- packaged apps running MediumIL (or higher). Does the equivalent of ApplicationData.Current.
  • If you're a packaged app running MediumIL (or higher) you can call Windows.Storage.ApplicationDataManager.CreateForPackageFamily(Windows.ApplicationModel.Package.Current.Id.FamilyName) for the equivalent to ApplicationData.Current
• %LOCALAPPDATA%\... and HKCU\... -- the long-standing guidance for per-user data if you lack package identity. The functional equivalents to ApplicationData's locations:

ApplicationData	Unpackaged
LocalCacheFolder	%LOCALAPPDATA%<publisher><product>`
LocalFolder	%LOCALAPPDATA%<publisher><product>`
TemporaryFolder	%LOCALAPPDATA%\Temp
LocalSettings	HKCU\SOFTWARE\<publisher>\<product>

[DrusTheAxe]

See Microsoft.Storage.ApplicationData #2639