Reputation: 71
Question Background:
I am calling a batch file to run a specified dll against the MSTest.exe through the use of a Process object.
The code:
I want to ensure that at all times this process is run with elevated administrator permissions.
I do this currently by setting the process verb
property to runas
, as shown:
try
{
_process.StartInfo.Verb = "runas";
_process.StartInfo.CreateNoWindow = true;
_process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
_process.StartInfo.Arguments = testLocation + " " + testDll;
_process.StartInfo.FileName = batchFileLocation;
_process.Start();
_process.WaitForExit();
}
catch (Exception ex)
{
throw ex;
}
The issue:
This runs as expected but the User Account Control (UAC) prompt asks to confirm that I wish the process to run the .exe.
As this code is part of an an automated process I cannot have any human input to click the 'Yes' button on the prompt, how can I disable the UAC prompt?
Upvotes: 1
Views: 2887
Reputation: 21
We should never disable the UAC, but we can get UAC to automatically raise permissions using our Administrative account without going through the UAC dialog. Of course, we have to have Administrator permissions in the logged-on account.
Doing this is easy. I found it accidentally while spelunking the dark catacomb's of Microsoft documentation.
Launch the Local Security Policy app (secpol.msc) through Win-R. Open the Local Policies tree branch and click on Security Options. Scroll down the Policy list for the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" entry and double-click it. Select "Elevate without prompting" from the combobox dropdown, then select OK.
Now, UAC will be protecting our systems without nagging us for elevating to Admin credentials. It will do it for us automatically. Even so, if someone logs on using an account without administrator privileges, they WILL get nagged.
Upvotes: 1
Reputation: 257047
You cannot bypass the UAC prompt.
Ask yourself: What would you do if you were doing this on Windows XP?
Imagine you were running on a operating system that did not have UAC. What would your dll do then? You no longer have the convenience of UAC, and instead you are always running as a standard user. What would your test regime do then?
If you don't like the UAC dialog you can turn it off. But you'll be in a no better situation, because now you're just like you were on Windows XP: a standard user and no easy way to get out of it.
The real solution is to fix what your dll is doing that is protected. For example, if this is a COM dll, and the self-registration is failing because you are trying to write to HKLM, then you need to
If your dll is crashing because you are trying to write to C:\Program Files, then you need to change the security settings on C:\Program Files
to give yourself access.
The solution is to fix what is failing.
Upvotes: 0