As we know, UWP is much more ring-fenced than its previous brethren; good old Windows Forms and WPF (Windows Presentation Foundation). This is with good reason though, as Microsoft designed this technology with the Microsoft Store as a fist class passenger. This primarily means 2 things: security and compatibility. Above all, the security restrictions are perhaps the most noticeable. One of the key things to note about this technology is that it does not inherently support file access outside of the application’s LocalState folder.
For instance, we have been working on a B2B enterprise application where we needed to place dependency files in a centralised location on the device. This is due to the fact that a variety of applications would need to consume these files. The issue with the out-of-the-box UWP strategy of copying these files into the LocalState folder was not viable for a few reasons; mainly due to the fact that these files are very large (in the order of 1TB), as well as the files needing to be duplicated across each application installation.
So, just use the Windows.Storage API for File Access. Duh!
Well, you see, there is the capability baked into the UWP framework that does allow file access to files outside of the app directory if the user has selected them via the UWP FilePicker.
In our case however, we were merely passing these file paths to a 3rd party component which then acted upon the files, which meant we had no control over how these files were opened. Therefore, this had no value to us.
What about the restricted capability “broadFilesystemAccess”?
Since this was a B2B application that was distributed via InTune, we didn’t mind using restricted capabilities, as there were no store acceptance criteria to be met. So, we set off adding this capability. It worked. Only for the Windows.Storage API and not System.IO (which we assumed the 3rd party component was using to read the files). Square one. Again. So now what?
So, after toiling away at the issue at hand, we finally found a solution that worked for us using the ALL_APPLICATIONS_PACKAGES group assignment to our shared folder.
Because of the fact that this is a B2B application, the devices were all pre-configured using MDM scripts, so adding this right to the script was a piece of cake (and fit our existing process well).
- In Explorer, navigate to the folder that you want to share between your applications
- Right-click -> Properties
- Next, click the Security tab
- Just below the “Group or user names” list box, click the Edit button
- Click Add
- In the object name text box, type “all” (without quotes)
- Click Check Names
- If it doesn’t come up with any objects, you may be in your domain. To change this, click Locations, and select your local computer
- Click Ok
- Then Apply
- Now click Ok again
- Finally, click Ok again
Voila! Your applications should now be able to access this folder freely, with no extra config or capabilities defined.
EDIT: Still not working
I have noticed that in some versions of Windows 10, the above still won’t work after applying the necessary changes. I am not sure if it is a security update, but I wasn’t able to uninstall each update manually and confirm. So, in addition to the above, you will need to go to Settings -> Privacy Settings. Scroll down the left pane to “File System”. Ensure that “Allow apps to access your file system” is turned on. Also, scroll a bit further down and ensure your app is listed and has file system access turned on.