Elevate your packaged apps with the new ‘allowElevation’ capability. With the 1809 update for Windows 10, apps can now declare this new capability in order to require elevation – or elevate themselves dynamically when needed. I will explain the new capability with three samples in this mini-series of posts:
1 – “Hello Elevated World” – simple packaged elevated desktop app (this post)
2 – Desktop app self-elevates dynamically when needed
3 – Elevated extension to a UWP application
As with all restricted capabilities, be sure to read the official Microsoft documentation regarding current policies for distribution via the Microsoft Store:
https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations#restricted-capabilities
Outside of the Microsoft Store you can of course distribute your apps with any restricted capabilities.
Hello Elevated World
TL;DR
I already have the 1809 update and the Windows SDK 17763 (or later) installed. Just show me the code …
Sample Code Repo on Github
Step-by-Step Tutorial
1. Create a new desktop application
Make sure you run Windows 10 with the 1809 update and have the Windows SDK 17763 (or later) installed. Now create a new C# desktop console application in Visual Studio 2017 (can be any type of desktop application really):
2. Add a few lines for testing
static void Main(string[] args)
{
Console.Title = "Hello Elevated World!";
Console.WriteLine("Press any key ...");
Console.ReadKey();
}
3. Add app manifest and require elevation
Project | Add New Item … | Application Manifest File
Open the app.manifest file and change the requested execution level from “asInvoker” to “highestAvailable”:
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
Now verify that running the unpackaged app will run as elevated after popping up the UAC prompt (unless you have turned this off).
4. Convert to a packaged app
Add a Windows Packaging Project to the solution and call it “Package”:
Be sure to set both “Minimum” and “Target” version to 17763 or higher as build number 17763 maps to the 1809 update for Windows 10:
Reference your desktop console application from the packaging project by right-clicking on the “Application” node under the “Package” project and selecting “Add Reference …” :
Now set the “Package” project as your startup project in the solutions settings:
5. Final Step: add the ‘allowElevation’ capability declaration
If you now hit F5 to run your packaged console app you will see the expected error stating that the launch failed because it requires elevation. This is the correct default behavior for packaged applications.
With the new ‘allowElevation’ capability apps can now properly disclose that they will/may request to run with elevated privileges. So let’s add this capability in Package.appxmanifest:
<Capabilities> <Capability Name="internetClient" /> <rescap:Capability Name="runFullTrust" /> <rescap:Capability Name="allowElevation" /> </Capabilities>
Hit F5 again and you will see your packaged app requesting elevated privileges and then run as elevated process:
And we are done! You have now implemented your first packaged app that runs with elevated privileges. To create the actual distribution package for your application you would follow the usual steps: Select the “Package” project in solution explorer, then go to Project | Store | Create App Packages …
In the next post I will cover how a packaged app can self-elevate itself dynamically, for example to access a file that requires administrative privileges.
AllowElevation Samples Part 2 – Dynamic Self Elevation
Insights into the Universal Windows Platform 
I am getting the elevation error even after updating the manifest file with elevation.
In my case, i call UWP->Win32 App(C++). I did change the UAC Execuation Level in my project Linker| Manifest File| UAC Execution Level.
Am i missing anything?
LikeLike
Are you using FullTrustProcessLauncher to directly launch an EXE that declares itself as requiring elevation? This won’t work. You will have to do it as described in part 3 of this series, i.e. self-elevate yourself from the Win32 EXE (or launch a third process which can require elevation).
LikeLike
In my case, i have 3rd process, so it worked, i have created the 3rd process as runas , so it elevated the process.
I am thinking of running a single background desktop process for doing, is it possible, UWP is directly calling win32 background process that requires elevated rights?
Thanks
LikeLike
Today it’s not possible directly from the UWP. But you don’t need a third process, you can runas yourself from the Win32 background process that the UWP launches (as my sample in part 3 demonstrates).
LikeLike
After changing ‘Enable UAC control’ to No, it worked fine.
But I have a different question.
My Win32 App uses other configuration files, how do i package those files in the appx files?
Thanks
LikeLike
If you mark them as “Content” in your VS project, then the packaging project will put them into the package for you.
LikeLike
Thanks Stefan!
LikeLike
You might want to add that this “…will only be approved for line-of-business apps deployed by enterprises to their private store via the Microsoft Store for Business.” ( https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations ) We discovered this the hard way, after investing wasted time.
LikeLike
This is a personal blog, not official Microsoft documentation. I won’t make any statements about Microsoft Store policies as those are subject to change and outside of my control. My blog posts aren’t suggesting that elevated apps would be suitable for Store submission. As with all restricted capabilities you should always refer to the official Microsoft Store documentation about current policies. I have added a note to my post along those lines. Thanks for your comment!
LikeLike
Thank you for your reply. We also didn’t mean to imply it was because of your post that we spent the development time. It wasn’t.
LikeLike
Hi, stefanwick! Thanks for you great article again! It help me a lot!
My question is that, consider to Microsoft Store policies. So personal developer cann’t submit APP with Elevation capability. That’s why you don’t have sample APP in Microsoft Store, is that right?
For me, I create a WCF service host in console app. And I have a UWP project communicate with this WCF service. There is a packaging project contains UWP APP and console APP through Desktop Extension.
It will show UAC window and works well when I run it on Windows 10 Pro. But it always be block on Windows 10 S mode.
LikeLike
Yes, apps with allowElevation are typically not suitable for Store distribution. Think about this way: Store users are generally non-admins. If they purchase an app/game that requires elevated privileges they wouldn’t actually be able to use it.
For your scenario I am wondering why you even need elevation. A UWP can communicate with a Console app through other means that don’t require elevation, for example through an AppServiceConnection.
LikeLike
Hi Stefan,
Would this work in the context of a standard user account?
Regards,
Sriram
LikeLike
For executing the elevated operation the user needs to provide credentials that have elevated privileges. So the user itself is not administrator, they will get prompted for user credentials that have administrative rights. Of course the non-elevated parst of the application will just work as normal for a standard user.
LikeLike
Thanks Stefan for the response. We observed similar behavior as you said. Wanted to follow up with another question if you can help with if we would want to build an Application Installer for managed (MDM) devices in a non-admin scope what are the APIs or concepts that we should be looking at?
Basically we are able to push UWP and MSI using Windows 10 CSP, but it is with the executables that we are stuck at, what we would want is when an Admin pushes an Executable app, install them silently even on non-admin users, but we are not sure how to approach this problem. We have seen applications that are able to do this and are wondering which API allows this 🙂
LikeLike
Sorry, this is not my area of expertise. I have left the Windows Application Platform team two years ago, working on Azure now these days. Any of my prior knowledge in this space might be outdated. Try reaching out to the MSIX Tech Community – they should be able to advise you there: https://techcommunity.microsoft.com/t5/msix/ct-p/MSIX
LikeLike
Hello Stefan. Do you know, why this example stays in Debug mode (when running with F5) even after the console application has exited? I tried to run Visual Studio elevated itself with the same result. This, however, is not happening with a self-elevated console application that was run from UWP that was started with FullTrustProcessLauncher API (as described in part 3).
LikeLike