(Updated 5/10/2012 – I originally claimed that it was “trivial” to make a ClickOnce app require elevation – a commenter pointed out that ClickOnce does not support the requireAdministrator execution level at all. This does not let the vendor off the hook – they should not have used ClickOnce to deploy software that requires features ClickOnce does not support… FYI – there are workarounds from the deployment side)
One of our vendors distributes a couple tools as ClickOnce applications, but these applications perform privileged tasks that do not work with UAC enabled. A ClickOnce application cannot be elevated, nor can it be specified that it requires elevation, so the only way this application would have ever passed testing is if UAC was disabled on the developers’ machines, or Visual Studio is run as administrator)
Rant: UAC has been around since Windows Vista was released in 2006. As of this writing, that would be 6 years. Windows 7 has been out for 3 years. As much as some people might dislike the extra dialogs, UAC is a very good thing, and should not be disabled. There is no excuse for applications that do not handle UAC correctly. Adding the appropriate application manifest is not difficult, and when using ClickOnce it is practically trivial (5/10/2012: Errata: ClickOnce Doesn’t support UAC – I was thinking about Full Trust) and if an application requires elevation it should be distributed standalone or with an MSI setup project.
Don’t use ClickOnce for applications that require elevation; Add the Application Manifest with a setup project to require elevation; or better yet modify your app to not require elevation at all, but do not just pretend it doesn’t exist. 6 years… come on!
Ok, now that my rant is out of the way, if you are in a similar situation – a ClickOnce app that needs elevation to run, but doesn’t request it is a real pain in the butt.
“Run as Administrator” is conspicuously missing from the context menu:
