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:

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.

[danmoseley]

@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.

[danmoseley]

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

[danmoseley]

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

[danmoseley]

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

[danmoseley]

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?