UWP vs .Net Framework File Access

Source: https://github.com/Corey255A1/.NetStandardFileSystemInterface

For better or worse I started working on a UWP (Universal Windows Platform) app that I have published to the Microsoft Store. It is still in a hidden state so that I can continue testing it before publishing out to the rest of the world.

Due to the sandbox nature of UWP applications there are quite a bit of differences between UWP and just writing a plain old .Net Framework application. One being that Loop Back network connections are disabled and another being reading and writing off of the filesystem.

The application I've been working on starts a really simple HTTP server - (https://www.wundervisionenvisionthefuture.com/post/net-standard-simple-http-server-websockets) - and allows people to play the game while the controller operates the app. The problem is that due to the loop back restriction, looking at this site from the same computer that is running the app is impossible. (Without jumping through hoops: https://stackoverflow.com/questions/33259763/uwp-enable-local-network-loopback)

Because of this, I decided to just spin out the game hosting portion into its own dll and build a simple WPF (Windows Presentation Foundation) frontend for it. This way, I can run the same game hosting code and test the webpages without using a VM, which I had been doing for testing. To use the DLL between .Net Framework and UWP, I put it in a .Net Standard 2.0 DLL. Your UWP project has to have a minimum target of the 16299 version or higher to use those dlls.

A Big hurdle for this was the difference in file access. The code I was refactoring would look in a folder and load all of the objects into memory. UWP does not allow the app free reign of the filesystem. The only files it can access are ones it has created in its own sand box, or ones that the user has explicitly chosen using a FilePicker. The API it uses is within the Windows.Storage namespace. You have to access objects using a StorageFile, StorageFolder, or StorageItem (Which both StorageFile and StorageFolder derive). If you use the classic System.IO objects they will throw File Permission errors.

To make something that I could share between UWP and .Net Framework, I created a new interface that I then implement in both UWP and .Net Framework. Then to use the calls in the DLL where in the past it would pass in a StorageFolder, it now passes an IFileSystemObject.

Looking at the interface implementations between the .NetFramework and UWP you can get a sense of what the equivalent calls.

The demo source and projects are here:

https://github.com/Corey255A1/.NetStandardFileSystemInterface

Below are the snippets.

I haven't added any Writes yet, but using this, it would be trivial.

All of the UWP file system calls are async and need to be awaited. So in the Interface, I defined all of the methods to return Tasks. You can add the Async call without ruining the interface.

The .Net Framework calls however, are synchronous. So in order to return a Task and be awaitable, they have to be wrapped in a Task.Run() call.

So there you go, if you want to write a Library that accesses the filesystem in both UWP and .Net Framework applications, you can go this route!