UAC and Your Application

Okay, so there’s this snarky little asshole who thinks he can tell me what to write.  “Go write a UAC Manifest article”, he says.

FINE!

There won’t be much too it, of course, which is a good thing – it’s easy to understand, easy to implement, and works as intended.  Of course, this is all assuming you’re using Visual Studio 2008.  If not: time to upgrade, chump!

So, you’ve written this wonderful little application does that wonderful little things.  You’ve tried it on XP, and it works perfectly.  Ditto for Windows 2000.  It crashes horribly on Windows ME, but that’s okay – so does everything else.  But on modern versions of Windows – Vista, 7, Server 2008 – things get weird.  Luckily, you’re a bad-ass hardcore cowboy coder who instantly knew you were running into UAC issues.  Solution: “Run as Administrator”.  Done!

But wait a minute… look at some of those fancy Microsoft programs like mmc.exe that automatically ask to run as an administrator.  How’d they do that?  Well, as a loyal Slick IT reader, you no doubt already read our article on UAC and Application Run Levels, right?  So you already know that you can configure your application to run in one of three ways:

RunAsInvoker: Runs as a standard user (unless the user has UAC turned off or chooses Run As Administrator somewhere along the line).  You’ll never get a UAC prompt.  Consider this “Never Elevate”.

RunAsHighest: Runs with the highest privileges the current user has.  For Standard users, the program will just run.  For Administrators, the program will run elevated, with a UAC prompt if needed.  Consider this “Elevate If Possible”.

RunAsAdmin: Always runs elevated.  A UAC prompt will be shown (unless the user is already elevated), and Standard users will be asked for Administrator credentials.  Consider this “Always Elevate”.

There’s actually a third option, and this is what’s used for running older programs.  If you don’t specify any of the above, Windows assumes your program doesn’t know about UAC and handles everything for you.  This includes File and Registry Virtualization.  Meaning, if your program tries to write to an area like C:\Program Files, it will appear to succeed.  In actuality, Windows virtualizes these changes under the current user’s account but keeps the actual Program Files folder unchanged.  I’ll write more on this virtualization later.

Here’s how you configure your application to use one of these run levels:

1. From Visual Studio, choose Project, Add New Item:
   
   Keep the default name and just click Add.
2. Replace the blue “asInvoker” (towards the end of the file) with “requireAdministrator” or “highesetAvailable” if you really think you need to.
3. Save, run, celebrate.

Fine, fine.  But how do you make your application elevate when the user clicks your snazzy Options button with the UAC Shield icon?  Simple: you don’t!  That is to say, your application is either elevated, or it isn’t.  This is determined before a single line of code is executed.  The only ways to get around this are to either launch a separate .exe that contains your options dialog and has “requireAdministrator” set, or restart your main .exe as an administrator.

Pain in the ass?  You bet!  Life would be so much easier if everybody just ran everything as Administrator all the time.  And while we’re at it, let’s abolish passwords, too… those can also be a pain in the ass.