Various errors/warnings in Visual Studio when writing to ApplicationData.LocalSettings

[JosHuybrighs]

Describe the bug

I am using Windows App SDK v1.0 in a Desktop app (wap-packaged) and are seeing errors/warnings in Visual Studio when assigning key/values to ApplicationData.Current.LocalSettings.

Issue 1:
ApplicationData.Current.LocalSettings.Values["AString"] = "1234";
Generates:

onecoreuap\base\appmodel\statemanager\roamingrpc\stateroamingrpcclient.cpp(124)\Windows.Storage.ApplicationData.dll!5125D7B9: (caller: 51267C88) ReturnHr(2) tid(1030c) 8007109A This operation is only valid in the context of an app container. 

This issue was originally reported on issue #1909

Issue 2:

ApplicationDataCompositeValue composite = new ApplicationDataCompositeValue();
composite["TaskId"] = result.TaskId;
ApplicationData.Current.LocalSettings.Values["AComposite"] = composite;

Generates:
onecore\base\appmodel\statemanager\apiset\lib\stateatom.cpp(593)\kernelbase.dll!772F3595: (caller: 772E68DF) ReturnHr(2) tid(1d770) 8007007A The data area passed to a system call is too small.

It seems that these are not really errors because the data is actually saved successfully but the messages are very annoying.

Steps to reproduce the bug

1. Create a Windows App SDK 1.0 project.
2. Assign a string and composite key/value to ApplicationData.Current.LocalSettings.Values

Expected behavior

There should be no error/warning in the output window in Visual Studio.

Screenshots

No response

NuGet package version

1.0.0

Packaging type

Packaged (MSIX)

Windows version

Windows 10 version 21H1 (19043, May 2021 Update)

IDE

Visual Studio 2022

Additional context

No response

[alexlamtest]

@JosHuybrighs
Thank you very much for reporting the 2 issues:
Issue 1:

1. The source file "stateroamingrpcclient.cpp" no longer exists in the latest code base; hence, the error/warning in question should automatically go away in future releases.
2. I noticed in Multithreading issue when setting a key/value in ApplicationData.Current.LocalSettings #1909, you said "... seems to indicate that LocalSettings cannot be used in a WinUI Desktop app". I believe the scope of the problem is not limited to LocalSettings; if the part of your app invoking ApplicationData APIs is indeed not running in an App Container (as the warning's text suggested), then the error/warning is legitimate. A client that is not running in an App Container must open ApplicationData using this API: https://docs.microsoft.com/en-us/uwp/api/Windows.Management.Core.ApplicationDataManager?view=winrt-22000, while a client that is running in an App Container must open ApplicationData using this API instead: https://docs.microsoft.com/en-us/uwp/api/windows.storage.applicationdata?view=winrt-22000.

Issue 2:

1. Right, this is not an error (at least not a fatal one), but a warning. The code (stateatom.cpp) that logs this entry sits at a low level, well beneath all language projections, so it does not have the full context to differentiate between 1) the caller indeed allocated insufficient buffer to hold the output and there is indeed a programming error, and 2) the caller intentionally was trying a small buffer first and if the API call returned "insufficient buffer" error then it would accordingly allocate a big enough buffer and retry the same API. Therefore, the code logged the entry for fear of hitting case 1. I will file a bug to track potentially disabling this entry to help reduce noise.
2. Therefore, issue 2 does not look correlated to issue 1.

Thank you very much.

[JosHuybrighs]

@alexlamtest Thanks for the feedback.
I added the explicit request to get the ApplicationData object and indeed issue 1 (not running in an app container) is gone.
For those interested, this is how to do this:
var localSettings = ApplicationDataManager.CreateForPackageFamily(Package.Current.Id.FamilyName).LocalSettings;
The warning in stateatom.cpp saying 'data area too small' is still there but I understood that a bug has been filed. I can live with that.
For me the issue can be closed.

[alexlamtest]

Closing this per @JosHuybrighs's comments.

[sjb-sjb]

Maybe consider reopening this issue for further investigation or documentation. I built an app using the WinUI 3 Desktop App (packaged) template and called ApplicationData.Current.LocalSettings from within a class library built from the WinUI 3 Class Library template (the class library method was being called from the UnhandledException handler of the app). In Debug mode it worked but in non-Debug it threw an exception. Calling ApplicationDataManager.CreateForPackageFamily instead of ApplicationData.Current seemed to work.

Sorry I don't have a standalone example.