There is a debate going in our department to remove local admin rights to the development workstations we use. I believe this will cause problems for the developers when trying to debug or run other tasks in Visual Studio but I can't put my finger on any one thing to support my argument.
What features or tasks require Visual Studio to run under a local admin account?
What do you think?
Visual Studio is designed to run in an environment without the need for administrative permissions. In general it does a good job at this and really only requires admin permissions when forced by the underlying operating system. Here are the few places I'm aware of that require this out of the box
Registering a COM component as a part of an F5
Debugging certain web project deployments on an IIS server
Attaching the debugger to processes running as Admin or other users
I'm sure there are a few more but these are the ones that come to mind. Note many of these can be worked around by making the scenario more limited user aware.
Development (= creation & debugging) of:
Windows services
A website in IIS (you can use the Development server, but its not the same)
Installation (MSI) packages
(Hardware-) drivers
Other system hooks
As an example of the project types mentioned in other answers, Visual Studio Tools for Windows Azure requires running VS in admin mode because the Windows Azure SDK's local dev fabric (cloud simulation environment for local debugging) runs in admin mode. This falls under the category of debugging processes that are running in admin mode.
If you aren't an administrator, you will need to be added to the Debugger Users group.
See also here.
Related
I know there are a few topics similar to this but none have my main issue in mind. I don't want to run Visual Studio 2017 as Administrator. Why should we be forced to run it this way? In doing so you lose a few abilities:
ability to simply drag files to the solution explorer to add them to your project.
Cleanly stopping a debugging session by closing IE or stopping the debugging within VS (and it will close IE for you).
There may be others
For posterity the error is:
Unable to start debugging on the web server. IIS does not list
a web site that matches the launched URL.
I have already followed the advice thusly:
Start >> Control Panel >> Click Programs
Click Turn Windows features on or off.
In the User Account Control dialog box, click Continue
Expand Internet Information Services, expand Web Management Tools, and then expand IIS 6 Management Compatibility
Click to select the IIS Metabase and IIS 6 configuration compatibility check box, and then click OK.
I do not wish to use the IIS Express included with VS but the real local IIS I have installed.
This did not solve the issue. I have yet to find a solution that will allow me (us) to run Visual Studio 2017 and use local IIS without running it as administrator. Can anyone provide a solution?
I'll reference this article as similar but it doesn't resolve the base issue: Debugging website on local IIS without administrative privileges
Refer: Why run Visual Studio as "Run as Administrator"?
Its mentioned with MSDN reference that Administrator permissions are required If we need for
Debugging applications that a run under a different user account, such
as ASP.NET websites.
I have a administrative account on my machine, but due to security reasons, I don't want to run visual studio as administrator. I have ASP.NET website, windows 10, IIS8. Is there is any way way to debug website without run pool with my credentials, or run visual studio as admin, or any other method, with insufficient privileges? I wanna tune my windows to allow me debug my application, and don't use brute force like "run as admin".
For winXP exists a this article this
As per https://msdn.microsoft.com/en-us/library/kd3se23d.aspx:
if you change the ASP.NET worker process to run under your own user account, you do not have to be an Administrator on the server that is running IIS.
I can't do it (as illustrated in my question).
Boklucius's citation is accurate, but I believe that article and the current update are misleading. I found that when running the app pool under my own credentials, I'm still unable to attach unless running Visual Studio as an admin. Lex Li observed that this was due to session isolation, and right now the evidence from my experimentation suggests he's right.
What is the difference between using Visual Studio 2012 "Run as Administrator" mode and otherwise? Why do developers prefer using VS in administrator mode? What are the advantages/privileges that one gets?
I may be naive enough to ask this one but I am just curious. Thanks.
From MSDN: User Permissions and Visual Studio
You can do nearly everything in the Visual Studio IDE as a normal
user, but, you need administrator permissions to complete the
following tasks:
Installing Visual Studio.
Upgrading from a trial edition of Visual Studio.
Installing, updating, or removing local Help content.
Developing solutions for SharePoint 2010.
Acquiring a developer license for Windows Store.
Adding classic COM controls to the Toolbox.
Installing and using add-ins that were written by using classic COM in the IDE.
Using post-build events that register a component.
Including a registration step when you build C++ projects.
Debugging applications that run with elevated permissions.
Debugging applications that a run under a different user account, such as ASP.NET websites.
Debugging in Zone for XAML Browser Applications (XBAP).
Using the emulator to debug cloud service projects for Windows Azure.
Configuring a firewall for remote debugging.
Profiling an application.
Deploying a web application to Internet Information Services (IIS) on a local computer.
Changing how you participate in the Visual Studio Customer Experience Program.
Windows Vista introduced User Account Control which means that you are running all programs as a standard user even if you are an admin. There are certain things that you in VS that requires you to be running as an admin, not a standard user. For example running Windows Azure emulators, asp.net dev server, etc.
You can run VS as a standard user but sooner or later you will run into issues.
How can I run my application on another machine, my team member wants to view the webpage in his computer. He doesn’t want to install visual studio but just wants to see the webpage in the browser.
I am using a Mac book
Publish it to a web server, or have him install IIS on his machine and set it up.. wait. That would be publishing to a web server.
In short, an ASP.NET website needs a web server to run. Usually it's IIS, but if you have Visual Studio, it uses the built-in Cassini web server. Either way, you need to have it in a web server of some kind. You can't just run it as a stand-alone program.
I haven't' done this, but I think you COULD have it running in your computer in Visual Studio and still have him see it. If you run it, you'll see that the address is in the format:
http://localhost/:[some port number]/YourWebAppName
If you have it running in Visual Studio on YOUR machine, your team member MAY be able to access it by changing "localhost" to your PC name. It's worth a shot.
Otherwise, here are a bunch of links to how to publish your site, in case you're not sure.
http://www.google.com/search?q=publishing+asp.net+web+sites&sourceid=ie7&rls=com.microsoft:en-us:IE-Address&ie=&oe=
Create a new virtual directory in IIS
Set the directory root to your project root folder.
allow anonymous access.
Your team member can then access it at http://yourmachinename/virtualdirectoryname
This looks like a good job for IIS express http://learn.iis.net/page.aspx/868/iis-express-overview/
For the majority of things, it's functionally equivilent to using regular IIS 7.5, with the exception that it's easier to start new websites with this. You simply use the command line to start IIS Express, point it to your physical path, set the CLR version, and the port, done!
http://learn.iis.net/page.aspx/870/running-iis-express-from-the-command-line/
There's some instructions for how to do that.
I've written many versions of windows services and installed them on a 64-Bit system with 32 GB running Server 2008 R2 Enterprise.
I create the services using this recipe:
http://msdn.microsoft.com/en-us/zt39148a.aspx
"Walkthrough: Creating a Windows Service Application in the Component Designer"
I create the .msi and corresponding setup.exe on my Win 7 laptop (c#, vs2010 SP1, .NET 4).
NORMAL BEHAVIOUR
after testing a Windows service on my laptop, I copy the .msi and setup.exe to a folder on the win2008 R2 Enterprise server (using copy and paste via remote desktop); I use the server's Control Panel to uninstall, right click the .msi and choose Install, then walk through the Setup Wizard. No problem. Works most of the time.
ABNORMAL BEHAVIOUR
The install runs for perhaps 15 minutes or longer; it never finishes; eventually a dialog states
"(?) Installer is no longer responding."
with options to [Retry] or [Cancel].
At this point, the progress bar is a short as it could possibly be and at the far left, beneath the "P" of "Please wait...".
Clicking Retry does not help. It's been over 30 minutes and counting since I clicked Retry and the progress bar has not advanced even a pixel.
MORE INFORMATION
(a) the service installs without any problem on another server, a Win 2008 R2 web edition.
(b) as mentioned above, the Windows service both installs and works properly on my Win 7 development and testing environment.
HISTORY / SPECULATION
a couple of weeks ago, I was unable to install a service from the win 2008 R2 Enterprise server. I could not find it in Control Panel/Uninstall even though the .msi claimed it to be installed and the service also continued to appear in the services.msc console. Even disabling the service did not help. For that reason, I cloned the code, changed the service name slightly, and successfully installed that service which has been running for while without issues.
Today, a similar event happened, the only difference being that I can see that service in Control Panel Uninstall. Because it would not uninstall, I tried my same cloning trick but this time it failed.
Next step: using the above walkthrough, I created a do nothing Windows service and made it useful by importing my client classes into it from the original c# project file.
The re-built from the ground up Windows service works as designed on my laptop but refuses to install on the R2 Enterprise server.
Any ideas?
Please and thank you.
P.S.: i posted this at so because imho it's more likely something that a developer is likely to encounter prior to handing off her/his code to a sysadmin.
BTW, I could not find anything related at so; ditto via Google.
in this particular case, it is some very weird server rights condition
MORE INFORMATION
although my server account is not Administrator, I'm a member of both local and domain Administrators for this 2008 R2 box.
I had tried many ideas, including creating the example in the walkthrough and trying it. No luck.
The boxe's Administrator was able to install my service using installutil.exe so I tried installutil.exe but it would only work for me using the Administrator's credentials.
For that reason, I suspected it might be a rights issue, so I tried with my credentials installing the walkthrough example on the H:\ drive. Success. Next, I tried installing the troublesome Windows service on C: in a different location. Again, success.
What is strangest about this issue is that many times I had no problem then suddenly a problem arose to block my development efforts.
A sign that a Windows service will install is when a dialog asking permission to continue appears almost immediately after starting the install. Another clue that success is possible is being able to successfully uninstall any previous version via Control Panel.
I appreciate everyone's efforts to help me with this. Thank you.
I've had similar experiences with my own MSI's (not just for services), as well as third party MSI's on Win2k3 and Win2k8. I never (ever) got to the bottom of it without a 'fresh' re-install of the operating system.
Just like you, I too speculate that there's something lost in (a combination or all of) the internals of the OS (registry, file-system, system restore).
I know this is not what you want to hear but (if at all possible) a clean install of the OS might do the trick for you.