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?
Related
I have a Windows 2012 system with Visual Studio 2010 installed. It worked fine on this system. Today I installed Visual Studio 2015 Community Edition on it. After installation, when I try to open existing solutions with Visual Studio 2010, the loading becomes very slow. Also, I am not able to save any modified files in the solutions. It seems that all the solution folders and files have become read-only. When I tried to change the attribute in Explorer, I was shown "You will need to provide administrator persmissions to change these attributes", even though I already logged in as administrator.
When I tried to save an ordinary text file, I was also not able to because some process is locking it. The same thing happens to C:\ as well.
Also, I notice that if I right click and select "New" from the pop-up menu in Explorer, the only option is "Folder" (this only happens for D:\ and not C:).
What could be the problem?
The local security policy was changed when I installed Visual Studio 2015 Community Edition. In Security Settings -> Local Policies -> Security Options, "User Account Control: Run all administrators in Admin Approval Mode" was changed to "Enabled". All I needed to do was to change it back to "Disabled" and then restart the system. The problems described disappeared after that.
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?
I have Visual Studio 2008 and 2010 installed side by side, but trying to open either a 2008 or 2010 sln file results in nothing. The hour glass comes on for about a second and then it goes away and nothing is opened.
I read somewhere to relate sln file to VS directly, but I can't go that route because I don't want 2008 solutions to open with 2010. Does anyone know what the problem might be and how to fix it?
If you are running Vista or Windows 7 with the UAC enabled and have "Run this program as an Administrator" checked on the Compatibility tab for the Visual Studio exe (devenv.exe), you will get this behavior when you try to open a sln file directly from Windows Explorer.
One solution is to go to "%ProgramFiles%\Common Files\Microsoft Shared\MSEnv" or ("%ProgramFiles(x86)%\Common Files\Microsoft Shared\MSEnv" for 64-bit systems) and right-click VSLauncher.exe and select Properties. On the Compatibility tab, check "Run this program as an Administrator". Now when you try to open a sln file directly from Windows Explorer, you will get the elevation prompt and it will open the correct version of Visual Studio for the file.
Apparently, the "run as administrator" hack does not work anymore in Visual Studio 2010 SP1. Fabian describes a workaround here:
Getting Visual Studio 2010 SP1 to run elevated when launching .sln files
To sum it up:
Backup VSLauncher.exe
From within a Visual Studio 2010 Tools prompt, extract the manifest from VSLauncher.exe:
mt -inputresource:"VSLauncher.exe" -out:VSLauncher.exe.manifest
Alter the VSLauncher.exe.manifest file:
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false">
</requestedExecutionLevel>
</requestedPrivileges>
Write back the manifest into VSLauncher.exe:
mt -outputresource:VSLauncher.exe -manifest VSLauncher.exe.manifest
The really annoying thing about this problem is that you have to run Visual Studio as administrator under windows 7 to attach to an IIS instance. The least they could do was not break the .sln files when you do that!
The post by Jorge Poveda is correct though, the original hack no longer works but his does. It's maybe worth mentioning that you have to run everything as administrator for it to work (the command prompt and text editor).
I think there is a better way though as we have Win 7 at work which runs as administrator and didn't have this issue. The key difference is that with this fix, the admin prompt asks you to open VSLauncher.exe, but on my work machine, it asks to open devenv.exe so VSLauncher must be OK to open VS2010 somehow. I'll ask our infrastructure guys how they did it and post back.
I am trying to install Visual Studio 2008 at a university's computer lab. The lab machines (XP Pro) are configured so that students don't have Administrator rights when they log in. So when I try to build or debug a class library project in Visual Studio 2008, I get this error: "Cannot register assembly 'C:\Documents and Settings(username)\My Documents\Visual Studio 2008\Projects\testproj\testproj\bin\Debug\testproj.dll' - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\test.cmdTest' is denied."
In previous versions of Visual Studio, there was the option to add the non-admin account to the Debugger Users and VS Developers groups, and this would enable them to debug and build DLLs. Does Visual Studio 2008 include similar functionality, and would this even be the solution? I'm not seeing the groups added with the installation. If this functionality is not included, is there another way to solve this issue? Allowing students to have Admin rights or Power User rights to the machines is out of the question.
Any suggestions, ideas, or insight would be much appreciated.
Why not just consider using some kind of virtualizations ? Install Visual Studio on a virtual machine, hence, every mess a student gonna make, is gonna be virtual to some extent.
Keep a ready and fresh copy of the image file though.
Probably not the answer you want, but you could start VS by right clicking VS2008/devenv.exe > "run as" and select administrator and have the lab tech enter the admin credentials. This way, VS2008 will have the required rights, but your school isn't giving out a sensitive Login/Password.
Your school should change the group policy to allow you to build your projects. Enlist the help of a friendly professor for that.
Are you doing a web application? I believe that for non-web applications, you do not need admin rights.
If this is not a web application, maybe it's just a file system permissions issue?
From:
http://msdn.microsoft.com/en-us/library/ms165100.aspx
"User permission requirements for Visual Studio vary depending on the operating system and the Visual Studio version. On Windows Vista, Visual Studio 2008 does not require administrator permissions to perform most tasks, but Visual Studio 2005 must run under administrator permissions to perform tasks correctly. On Windows Server 2003 and earlier, members of the Users group can perform most activities in the integrated development environment (IDE)."
It looks like you're trying to register the assembly in COM.
Access to the registry key
'HKEY_CLASSES_ROOT\test.cmdTest' is
denied."
Are you setting a [assembly:ComVisibleAttribute(true)] attribute in your assemblyinfo.cs or project properties? Try setting this to assembly:ComVisibleAttribute(false).