File Pickers not functional in PartialTrust applications

[zsolt3991]

Describe the bug

During migration of a UWP application to Windows App SDK it was noticed that File Pickers are not functional when using an AppContainer style app instead of a Full Trust application when packaged.

It is not clear which component in the dependency chain is actually responsible, opening the bug here on the premise of UI not being at fault since its a system dialog an not WinUI dialog. The exception happens in the WinRT Interop call and not user code.

This behavior is present since Project Reunion releases from 2 years ago, see the second linked post in the additional contents and does not seem like a recent regression.

Steps to reproduce the bug

1. Create a sample application project
2. Add File Open/Save picker following the Documentation for WinUI3/Win App SDK on Interop
3. Run the application and verify it works
4. Go into Package Manifest and change Entrypoint to => Windows.PartialTrustApplication and remove the runFullTrust restricted capability.
5. Build and Run the application again
6. Application will crash on trying to open the picker with Win32 Exception E_ACCESSDENIED in the call for InitializeWithAppWindow.Initialize()

Expected behavior

Application is able to open File Picker in partial trust mode.

This is base functionality that is possible in UWP which blocks the migration path of applications that perform any file I/O requiring user choice. In some cases running full trust is not allowed only by exemption from the rule, see Microsoft Store submission guidelines.

Screenshots

No response

NuGet package version

Windows App SDK 1.2.5: 1.2.230313.1

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

See links below:

Similar report in discussions: #3447
Post from 2021 with the issue on Project Reunion

[JaiganeshKumaran]

When running under partial trust, file pickers think there's always CoreWindow, which obviously isn't true in a WinUI 3 application. Microsoft needs to patch Windows to make this work.

[DarranRowe]

The interesting thing in all of this is that there is some mechanism in there for the file pickers to work in a partial trust desktop application.
The Windows 10/11 shell provided file dialogs actually forward things to the UWP file pickers. Of course, these end up being really broken in app container desktop applications since they are not in on the UWP security stuff, but they show something. This has never been made into a public API though.

[zsolt3991]

It is really weird to put all the effort into the next new thing to replace UWP, and end up with what is basically WPF with WinUI frontend. Had hopes that the 1.3.x AppWindow changes bring some help to solve this issue, but found out not much has changed.

One can get around for opening files to rely on Drag&Drop events, however clunky that would be for desktop use. For saving files, however that cannot really be used.

I wonder if it is even possible to create some custom dialogs relying on the other capabilities/permissions entirely in the AppContainer, looking at having broadFileSystem access for custom paths. Also wonder how something like .NET MAUI handles its pickers on Windows unless that also forces a runFullTrust capability.

[DarranRowe]

The biggest issue is that the app container is an operating system level thing. This means that without the co-operation of Windows itself, even the Windows App SDK isn't able to do much.
Also, even though the pickers themselves have issues, it is not like the filesystem functionality doesn't work. But the real fix for this is for this functionality to be fixed at the operating system level.

[mominshaikhdevs]

1. #219 - AppContainer for Win32 Apps

and

2. #8 -Improved StorageFile APIs