In a number of my previous posts I’ve challenged the need for Windows UI (WinUI3) to continue to support UWP. In nearly every instance I get push back from the community regarding all the features that are missing from Project Reunion and that UWP needs to be the future – but why I ask? wah, wah, wah, sandbox, wah, wah, wah, security. Most of the comments come back to the fact that Project Reunion is still very much a work in progress. However, the topic of “the sandbox” and the “app container” comes up repeatedly. In this post I’m going to quickly wall through how you can take a Project Reunion (aka WinUI3) app and get it to run in the Windows App Container, and thus running with similar restrictions as a UWP application.
To kick things off we’re going to start with an app created using the “Blank App, Packaged (WinUI 3 in Desktop)” project template. In the code behind for the Button (that’s created in the XAML of MainPage as part of the template) we’re going to access a file in the c:\temp folder – this is a file I know exists, so there should be no issue accessing it and writing a string to it.
private async void myButton_Click(object sender, RoutedEventArgs e)
{
myButton.Content = "Clicked";
var file = await StorageFile.GetFileFromPathAsync(@"c:\temp\simpletextfile.txt");
using var strm = await file.OpenAsync(FileAccessMode.ReadWrite);
using var textWriter = new DataWriter(strm);
textWriter.WriteString("Test output");
await textWriter.StoreAsync();
}
If we run the application at this point and click the Button, we can inspect the contents of the “simpletextfile.txt” and it will indeed have been updated to “Test output”. This indicates that our application is running with enough permissions to write to a file that exists in an arbitrary folder on the computer.
Further to this, we’ll open Process Explorer we can see that the Integrity of the application is set to Medium Mandatory Level. This is higher that the Low Mandatory Level we would see from a UWP application (I cover this in more detail in my post Combining .NET 5, WinUI, UWP – FullTrust, PartialTrust, WindowsAppContainer)
Let’s now change the trust level of our WinUI application. For this we need to do three things:
1 – Trust Level
We need to change the Trust Level property set on the application in the Packaging project associated with the WinUI application.
2 – Full Trust Capability
In the Package.appxmanifest file we need to remove the runFullTrust capability. Here I’ve just commented out the capability so that you can see which one I’m removing but feel free to remove the capability completely. You’ll need to keep the Capabilities element if you want to assign other capabilities to your app.
3 – Phone Identity
The last change we need to make is to add a PhoneIdentity element to the Package.appxmanifest. I’m simply setting the PhoneProductId to be the same guid as the Name attribute in the Identity element.
Now that we’ve made these changes if we run the application (make sure you rebuild and deploy your application again to make sure the manifest changes have been applied) and click the Button, the application will crash.
Running the application with the debugger attached we can see that when we click the Button an UnauthorizedAccessException is raised at the point where we attempt to access the text file.
If we now take a look using Process Explorer, we can see that the application is now running with an Identity of Low Mandatory Level (similar to a UWP application) and in the Windows app container.
The great thing about removing the “runFullTrust” is that you don’t need to explain to your users why your application needs to “Access all your files, peripheral devices, apps, programs and registry” (as seen in the permissions requested dialog for the Windows Terminal app).
