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.
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.
Short desc:
Same .exe when ran without administrator rights can use 32bit driver. However, when ran with admin rights it's incapable to use it/find it.
My environment :
Windows 7 64bit
Visual Studio 2013 Professional
.Net 4.5
Computer NOT in domain
Background story:
I have a WCF service hosted in consoleApplication and I'm connecting to it by WCF over net.Tcp (locally).
WCF uses for it's work VFPOLEDB.1 provider which is only 32bit. Everything works fine until I do some admin work inside application. It logicaly requires "Run As Administrator" to do it, so either Visual Studio 2013 (which hosts consoleApp) or Debug\xxx.exe must be run in "Run As Administrator" mode.
Caught exception says "VFPOLEDB.1 is not registered" (so main problem: application is 64bit and looking for 64bit drivers) ONLY when I use run as Administrator, I tried AnyCPU setting to x86 and project setting to x86 and none had effect.
Here is my question:
How can I run .exe/visual Studio 2013 in admin mode but force it to use 32bit drivers.
Thank you!
I got that problem for a MySQL DataSource, that's because your DataSource is registered only for your current user, not Machine-wide. When the application is ran as an administrator, the program is looking in the machine wide data sources
To register your DataSource System-Wide, open your Configuration Panel, in the search bar type ODBC.
Click on "configure ODBC Data Sources (32bit)"
There are two tabs that shoul interest you :
"User Data Sources" <= You should find your DataSource in there
"System Data Sources" <= You should register your DataSource here
If your program is compiled in 32bit and is run as administrator it will still use the 32 bit database drivers.
If i misunderstood something please tell so that i can adapt my answer
i finally finished a proyect i was requested in my university with Lightswitch. Im ready to deploy (publish) next week, and i was JUST told that the people that will recieve the software, are using XP machines. I've read a lot of questions and lots of fixes, to get Lightswitch working on Windows XP, like:
Changing the DumpBin with "editbin vslshost.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1"
deploy it as a desktop application with the services deployed to IIS (i dont think this will work because those are really old pc's)
install all the prerequisites manually and launch the ClickOnce application directly from deployment manifest file (.application)
create a sample ClickOnce application using Visual Studio 2010 OR Visual Studio 2008 with the same name as mentioned in Visual Studio 2012 and publish it. From the published location take the setup.exe bootstrapper and replace the existing setup.exe bootstrapper created using Visual Studio 2012
With all of this workarounds available, i NEED to ask, will this ultimately work? Can someone REALLY tell me that using one-or-all of this workarounds i WILL be able to deploy the application!?
Someone?
The 2-Tier Deployment issue on XP was also addressed in VS 2012 Update 2 IF you upgrade to a "V3" LightSwitch project by right-clicking on the root project in Solution Explorer and selecting "Upgrade Project". This updates the project to the "V3" project system, runtime and will use a much newer publish wizard. The version of VSLSHOST.exe that ships with VS 2012 Update 2 is compatible with XP.
Dave Kidder - LightSwitch team
http://social.msdn.microsoft.com/profile/dave%20kidder/
I have a successfully deployed application using the 3-tiers running as an out-of-browser (desktop app) on XP. Initially I was going to do the 2-tier deployment, but I was unable to get a workaround to work.
So I have one server, which runs IIS as well as my SQL server (OS is Windows Server 2003, but doesn't have to be.)
The client machines range from Windows XP to Windows 7, and I haven't had any special problems with windows XP.
So I can definitely say XP will work as a client. I was unable to get it to run the middle tier (hence IIS on the server) but I didn't try every last idea I found, so I won't say it's impossible.
The two links I found most helpful in the process were
http://blogs.msdn.com/b/bethmassi/archive/2011/03/23/deployment-guide-how-to-configure-a-web-server-to-host-lightswitch-applications.aspx
and
http://blogs.msdn.com/b/bethmassi/archive/2012/03/29/lightswitch-iis-deployment-enhancements-in-visual-studio-11.aspx
Hope that helps.
Is there a way to set up Remote Debugging (Msvscom.exe) on a machine that does not have Visual Studio installed?
I would like to attach to the service running on the VM so I can debug an issue in the code. I've done this before but both machines have had VS installed.
The Dev box is running Visual Studio 2010/Windows 7. The VM is running Windows 7 without Visual Studio.
I'm going to resurrect this because anyone who's tried to do this knows it's a complete pain in the ass every time, and that it changes slightly with every possible combination of host/remote system you can have.
Visual Studio Remote Tools Links:
Visual Studio 2010 remote debugger. (Working as of 21/Oct/2016)
Visual Studio 2013 remote tools (working as of 21/Oct/2016)
Visual Studio 2015 remote tools x86 - Direct download link
Visual Studio 2015 remote tools x64 - Direct download link
Visual Studio Tools (Thanks Robo Burned)
Visual Studio 2017 Remote Tools x64 - Direct download link (Thanks Isaac Baker)
Visual Studio 2017 Remote Tools x86 - Direct download link (Thanks Isaac Baker)
Visual Studio 2019 Remote Tools - download link
This is the setup I succeeded with today:
Host (Dev) Machine:
Windows 7 Ultimate SP1 x64. Running Visual Studio 2010, .NET Framework 4.
Remote Machine:
Industrial/Factory Floor PC running Windows Embedded Standard 32-bit. It looks/feels exactly like Windows 7. Running SP1. Visual Studio is not installed. Has the .NET framework 4.
Network:
Both machines are on the same subnet. I access the remote machine via RDP and run my application that way.
Microsoft-Proprietary Follicle-Deterioration Implementation:
Make note of your dev machine's user name and password. For some reason you have to create exactly the same user name and password on the remote machine. Because Microsoft.
How I did it:
I downloaded the Visual Studio 2010 remote debugger from the link provided by #sJhonny. I had to switch off of Visual Studio 2013 in that article and over to 2010. If you care to go over the 2010 article with a fine-tooth comb to find the download, the link is right next to the "No one ever finds this helpful" link at the top. If not, just follow my link above.
Install that on the remote machine and run the configuration wizard. I left the defaults for the wizard:
"Run the 'Visual Studio ....." was checked off
Username is LocalSystem and password is blank
Allow only computers on the local network....
Run the Remote Debugger on the remote system and you'll see
Msvsmon started a new server named 'username#machinename...'
in the interface. So far so good. Run the application on the remote machine. On the dev machine, Ctrl+Alt+P in visual studio will open "Attach to Process" (It's also under the tools menu). I got a popup about my dev machine's firewall not being configured properly and was asked if I wanted to allow the connections etc... Say yes obviously.
Enter the 'username#machinename' combination into the qualifier box... press Refresh and pray a little. Pray a little more a lot harder and you should see a list of the processes running on the remote machine. Select your process and attach to it.
But my breakpoints don't work!? Of course they don't... because using the breakpoints in the same directory as the application on the remote machine would make too much sense. If you were lucky enough, you got warned about a breakpoint cache and got shown a dialog with a path.
The dialog mentions something about it being correct relative to the remote machine. It's lying. It has nothing to do with the remote machine except that it forced you to create a brand new user over there with the same name as your current user because Microsoft. To get your breakpoints to work, follow the path on your dev machine (customizable in Tools>Options>Debugging>Symbols: Cache symbols in this directory) and copy your application's .pdb files over to that directory. You have to copy them over with every new build, unless there's an option to do it automatically; I haven't checked because I have yet to stop celebrating my remote debugging success.
Everything should work now.
certainly there is.
You can install msvsmon without installing visual studio.
I've done this myself on several machines.
the tricky part lays in authorization- the user running VS on your local machine needs special priviliges on the remote machine.
ms has some articles explaining the details- http://msdn.microsoft.com/en-us/library/bt727f1t.aspx,
Update:
Here's the links for 2017 which are not obvious to find either.
Visual Studio Remote Tools Links x64 direct link
Visual Studio Remote Tools Links x86 direct link
Taken from:
how-to-implement-remote-debugging-in-visual-studio-2005
Let's consider an example to understand this situation clearly. Molly
Clark and Adam Barr are both employees at Adventure Works. Adventure
Works has a Microsoft Windows NT domain named adventure-works.com.
Adam is having trouble with some software that Molly wrote. Molly
would like to debug this software on Adam's computer. Molly and Adam
follow these steps:
Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program
Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory
on her computer. She creates a file share called Remote.
Adam runs \MollyComputerName\Remote\x86\Msvsmon.exe.
After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions
dialog box. He gives Molly permission to debug.
Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.
Molly starts Visual Studio 2005.
To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
Molly connects to Adam's computer by entering adventure-works.com\Adam#AdamComputerName in the Qualifier box.
Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in
the application.
There's also another way which I prefer (if you have fast internet connection).
You don't have to download or install anything on remote desktop connection.
You can share your disk C: while connecting via Remote Desktop Connection.
On the remote desktop go to location (depending on your local location)
\\tsclient\C\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Remote Debugger\x64
(optional) Create shortcut to folder or msvsmon.exe on desktop
Run it remotely from your local disk via shared disk. (start can take few seconds depending on your connection quality)
Option2: Copy Remote Debugger\x64 or x86 folder to the remote location and use it.
I was able to get it working with asp.net core 2.1, the only difference from the answers above was that the process you attach to is dotnet.exe.
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.