Runtime: Change IO to use CreateFileFromApp2 etc when in UWP

[Foda]

Related to this issue. Pretty much all the System.IO.File functions won't work when used from UWP due to permission issues. I guess I shouldn't have been surprised, but it would be nice if somehow we could make those 2 APIs work together.

[karelz]

Which APIs in particular do you have in mind? Here's list of differences we're tracking: System.IO list
To my knowledge they should work just fine, beside the limits of UWP sandbox.

cc @JeremyKuhne

[Foda]

I suppose a better way to phrase this would be "document the restrictions the UWP sandbox has on System.IO" (from what I can tell none of the System.IO.File APIs will work -- File.Open, StreamWriter, ReadAllText, etc because they'll never get the permissions to do anything). From an interop standpoint this can be frustrating: you'll need to abstract away your file logic and then convert down the chain to use the "IStorageFile" versions. I also wrongly assumed that if I gave access to my app via a file open dialog that the non-UWP file APIs would then be allowed to access those files.

Ideally a warning or something would be nice (like in VS), and possibly a page documenting the restrictions of the UWP sandbox with .NET Standard.

[JeremyKuhne]

They currently don't work with paths from brokered locations. App data and temp directories should work fine. Note that we intend to have the brokered locations working in a future update.

As a workaround, if you have using System.IO; CreateSafeFileHandle() extension methods will be available on IStorageFile and IStorageFolder classes. For example:

C# var picker = new FileOpenPicker(); using (SafeFileHandle handle = picker.PickSingleFileAsync().GetResults().CreateSafeFileHandle(FileAccess.Read)) { StreamReader reader = new StreamReader(new FileStream(handle, FileAccess.Read)); // ... }

[Foda]

Ah, glad to hear that! Thanks for the tip too. By app data, you mean Windows.Storage.ApplicationData.Current?

[JeremyKuhne]

By app data, you mean Windows.Storage.ApplicationData.Current?

You can get to the path that way or through Environment.GetFolderPath(), which might be a little simpler. The paths to app data should work without jumping through the CreateSafeFileHandle hoop. Anything that happens to be ACLed for "ALL APPLICATION PACKAGES" should work directly as well.

[danmosemsft]

@Foda yes, unfortunately they don't do "brokering" which is what is required in order to access arbitrary locations. To do that, it's necessary to either show the user a picker, use the WinRT API, or get a raw handle and use File functions on that:
https://source.dot.net/#System.Runtime.WindowsRuntime/System/IO/WindowsRuntimeStorageExtensions.cs,9dfff5540cb50d08

This is something we plan to fix in future.

[danmosemsft]

Oops, my comment crossed (hadn't refreshed my page...)

[danmosemsft]

@Foda I updated the title if you don't mind, in order to track this work for us for RS4.

[danmosemsft]

Marking blocking-release to make certain this doesn't get lost.

[danmosemsft]

This is not scheduled for the current release.

[ViktorHofer]

Giving that the servicing bar for UWP is very high I doubt that we can change the existing behavior. @danmosemsft do you agree or should we keep this open?

[duke7553]

Hi. This should probably be reopened if UWP apps still have access to System.IO APIs. Will there be work done in .NET 5 to make them use the *FromApp methods? @danmosemsft @karelz

[karelz]

I don't think any work in this space is planned. @carlossanlop can confirm.

[danmosemsft]

There is no plan to do that.

[duke7553]

I thought the plan was to allow WinUI 3 apps to use the full range of .NET 5 APIs regardless of whether they opt in to the WinRT sandbox. Right now, we have a confusing situation where devs are told they can use System.IO in UWP apps, but get an AccessDenied exception when accessing locations their apps have permission to access via broadFileSystemAccess.

It's a bummer this won't be worked on when the fix is so easy.

[duke7553]

@karelz @danmosemsft @carlossanlop Having the .NET API Browser display these APIs for use in UWP with no information banner saying they do not work with brokered locations is bad design. I've been using DllImport to use the FromApp APIs instead of the WinRT equivalent in my Windows app. Things have been perfectly fine for us. In fact, we see a massive performance improvement using it.

Source: https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.getfilesystementries?view=dotnet-uwp-10.0

[duke7553]

They currently don't work with paths from brokered locations. App data and temp directories should work fine. Note that we intend to have the brokered locations working in a future update.

@JeremyKuhne Have the plans changed with this?