When I try to run a vs solution file, I cant do it with run elevated access...as that option is not showing up on right click.
There is no such option in VS. If your program requires UAC elevation to do its job then you have to ask for it in your program itself. So it will still operate correctly on the user's machine. Edit the manifest of your EXE project as described in this answer.
To debug such an app, Visual Studio needs to be elevated itself. It normally prompts you for that, but there's a bug in VS2013 that prevents that from working if the Visual Studio Hosting Process option is turned on. Avoid this bug, and the prompt, by starting VS elevated. Do so by right-clicking the shortcut and selecting "Run as Administrator".
Related
I used Visual Studio 2010 on Windows 7 for a while and never had this problem, but with the current VS solution whenever I run the executable created from any Fortran project (both debug and release) I get the message
This task requires this application to have elevated permissions.
and I'm asked to restart Visual Studio as Administrator.
I don't want this, I want to create executables that run not as administrator unless right-clicked => run as administrator. That has always been the case for all my solutions except this one and I cannot figure out what I did different.
How can I change this behavior?
In your project's linker properties there is the manifest file group of options.
Inspect the value of
UAK Execution Level
Probably it is set as
requireAdministrator
You should change it to
asInvoker
Using Visual Source Safe 2005, I downloaded a jobmate's project in my computer and built it correctly, but when I press "play" to debug it I receive an error message telling me that I need higher privileges.
Looking around, I've noticed that the freshly build program has the little shield icon that means that I need administrator permission to run it and actually, if I run it outside Visual Studio, I manage to execute it after the UAC question.
I'm domain and local administrator so I can disable UAC, but I don't think this is the solution, so: what can make my program to require administrative privileges?
First of all - this is all about the RTM Versions. And Windows 8 has some changes regarding the UAC, as we all learned from http://www.brianbondy.com/blog/id/140/, it cannot be disabled side-effect-free.
Now the problem starts:
Our main app requires elevated privileges (at least the server part). Debugging will only work when running VS in elevated mode, too. But when I'm starting a Silverlight Project in elevated mode of VS, the IE fired up for debugging is started as with normal privileges and debugging is not possible, too. To make things more complicated, we're not running solutions with all (700+) projects loaded, but do lot of our dev-stuff (compiling, starting, testing) in command line. Which needs to be elevated, too.
What is the correct configuration of UAC for this purpose: I want to be able to debug Silverlight applications running in Internet Explorer, Applications of any kind started by VS "F5", a server process started from commandline and (maybe) C#/XAML Metro-Apps?
In Windows 7 it was just disabling UAC and everything's fine. Now I feel like fighting against my own toolset and have a bad feeling about this.
And please - do not tell me that UAC is important and useful. I'm totally okay with it, but for a developer things are slightly different.
See this answer on Superuser:
The Only way I'm aware of which ensures it will always open as
Administrator (including when you open from file associations, jump
list etc) is:
Locate the devenv.exe file in Explorer eg mine is in C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\
Right-click devenv.exe and choose "Troubleshoot compatibility"
Select "Troubleshoot program"
Select "This program requires additional permissions"
You'll need to let it launch VS before it lets you click Next, but
then you're done.
EXTREMELY annoying that you can't just do this through the normal
properties dialog any more. It's like Microsoft are going out of their
way to ensure Windows 8 alienates as many people as possible...
Have you tried installing VSCommands and using the Always start Visual Studio with elevated permissions option? I'm not sure how this would function differently than restarting with elevated permissions but it can't hurt to try.
I ran into the same issues with the command line, debugging, and other things such as once you're running with elevated permissions you can no longer drag & drop files into Visual Studio, or open files associated with Visual Studio when it's set to always run with elevated permissions. This is why I've always disabled UAC.
In the end I just turned off UAC in the registry. I'm not missing out on anything by doing so. It would be nice to hear how Microsoft uses the Win8 + VS2012 combo internally after seeing how broken it feels.
My company uses ViewFinity to elevate processes that need admin rights in lieu of any kind of actual admin privileges. Visual studio is already elevated, but for some reason the JIT debugger doesn't run as admin. It is a separate .exe that kicks off when an exception occurs? How would I go about fixing this?
IT fixed the issue. Evidently when JIT debugger is launched, it launches a separate .exe (can't remember the name right now) which in turn launches visual studio.
I'm running Visual Studio 2008 on Windows 7 64-bit. I'm logged in as administrator, and I'm running it as administrator, but the program I'm working on fails with access denied when I call a restricted API. If run the program from Explorer with "Run as Administrator" it works.
I was under the belief that Visual Studio 2008 debugs programs with whatever rights Visual Studio 2008 itself is running with. As it stands I can't debug my application due to this, and I'm at a loss as to what's going on.
This works for Visual Studio 2012.
Create a manifest file: right click on the project and select "Add New Item", select "Application Manifest File". This will add a file named app.manifest to the project.
Edit manifest file: set attribute level for tag requestedExecutionLevel to requireAdministrator.
Now your program will always require admin privileges, wherever it is executed. If launched by Visual Studio debugger, it will prompt you for restarting Visual Studio as administrator, if needed.
It's best to run Visual Studio 2008 as administrator. Moreover, it's good to change your application's manifest settings to require administrator privileges. You will be prompted by the system to elevate to system administrator each time you start your application, and when running under Visual Studio 2008 the IDE will offer you the elevation before start of debugging.
To change the setting, open project properties and go to Configuration Properties → Linker → Manifest file → UAC Execution Level.
I found the answer. It turns out that it is, in fact, a manifest issue: by default if you have a manifest you need to set the appropriate administrator privilege.
The default is asInvoker, but that doesn't work if you need elevated privileges; you instead have to set it to requireAdministrator in the manifest properties.
Run Visual Studio 2008 as administrator.
I had a case where I put in the
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
settings (described by another answer at this post)........and did not work.
I found another tip (seen below)...and unchecking that option allowed my code to work.
Try going into the project properties, and under the "debug" tab,
uncheck "enable the Visual Studio hosting process" and see if that
fixes your problem.
(from https://social.msdn.microsoft.com/Forums/vstudio/en-US/b5c4da93-5d64-442e-af28-df6d10765538/debug-as-administrator?forum=vbgeneral)
So I needed the app.manifest settings AND the "uncheck".
My testing with Windows Vista and Visual Studio 2005 showed that when you use a host process, the behavior under the debugger depends only on how you launched Visual Studio and not on the manifest (or lack of manifest) of your application. When Visual Studio is launched elevated, the behavior depends only on the use (or not) of a host process, not on the manifest. This is probably still true with Windows 7 and Visual Studio 2008.
Also, have you tried launching the application outside Visual Studio and using Attach to Process?