Reasons to run Visual Studio 2010 as Administrator (UAC issues)

Unfortunately Visual Studio 2010 (even SP1 level) is still not fully prepared for Vista and Windows 7 UAC (User Account Control – basically where the Administrators group membership is ignored until you “elevate”).

Here is my list of why not, which you can use in case you need to justify it:

  1. First open of solution with IIS web applications bound to real local IIS web sites (not using the Visual Studio development server) – tells you to run as administrator because it can’t register the new projects with IIS as a normal user.
  2. WCF in IIS Web Site – cannot launch debugging of web services running below a normal web site path (HTTP/S with IIS compatibility) because it will fail to register HTTP URL security.
  3. Event Log Component Registration – fails to auto-register event source name in registry the first time you build and run a solution with an event log component, e.g. Windows Service.
  4. Help Library Manager – cannot change all settings and modify content, not even update!
  5. Azure – cannot debug solutions locally using the Azure Compute Emulator.
  6. Team Foundation Server – cannot create a new TFS team project because it tells you must run as administrator to configure Reporting Services.

Reasons NOT to run as Administrator are:

  1. Developers must get used to creating applications following the “least privilege” paradigm. The best place to do this is during creation of the application itself rather than ending up with a delay, because you have to re-design your GUIs and setup routines after integration test failures. From the user perspective that looks pretty dumb too.
  2. Compiling and running sample code downloaded from the internet (could be a Trojan). But this has a low chance, if you compile and run code from the internet and don’t look at it first it could still read your files and post via a web service without administrator privilege.
  3. Developing end-user GUIs or setup routines (e.g. WIX Custom Actions) which work with system resources or protected configuration data (e.g. IIS web site list in 2008 R2), testing that your code works with UAC elevation.

I guess Visual Studio 2012 will have more improvements in this area. But we are still waiting for a native 64bit Visual Studio so I think this list may live a bit longer. :-/

One alternative would be to mark project build events, builds, runs  or design as requiring Administrator privilege. Then most cases just the build elevates and you can still test the rest of the program at lower privilege. Only down side is it could get annoying with pop-ups. Automated builds should be okay because they normally run as fairly high privilege service accounts on servers without UAC.

I will update this list if I encounter more limitations. But I have to continue with some solutions as Administrator to get the jobs done so I may not encounter them. Suggestions welcome.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s