I use remote debugging in visual studio 2012 by using msvsmon.exe on the remote pc, but is there a way to merge this in the setup of the application so I dont have to add the folder to the remote pc and run the app and change the options. Now I know that I can embed it in the installer and run it from my application, but how do I set the options from my application, like the Autehentication mode.
Related
I have a beaglebone black wireless device that I am developing C# code for using Visual Studio on my windows 10 host machine. I would like to target my beaglebone board via SSH within Visual Studio so I can do a cross-platform build of my solution on my host machine (arm32), and then have that compilation run on the remote machine automatically without having to publish my solution for arm32 and transfer the binaries to the remote machine, etc. This is so I can create a Visual Studio collaboration and a colleague working remote can deploy to the remote device while in development.
I have been messing with Launch Profiles and adding my beaglebone board in the Visual Studio Cross Platform SSH connection list, as well as exploring the Attach Process area. While I can successfully connect to my beaglebone device via SSH from Visual Studio, I do not know if my real goal can be achieved. My device cannot run the Visual Studio 2022 Remote Debugger (MSVSMON) due to being a linux machine. Any assistance would be appreciated.
I've written a Hello World console app in .Net Core 2.0 using VS 2017 and deployed the Debug build to a Raspberry Pi 3 running Windows 10 IoT. I can execute the app remotely via PowerShell and everything seems fine.
Having installed the Visual Studio 2017 Remote Debugging tools, I'm now trying to hook up the Remote Debugger so as I can step through my code on the Pi and I'm running into problems.
When I try to "Attach to process" from the Debug menu in Visual Studio and enter the IP and port number supplied by the IoT device portal I get the following error:
Unable to connect to the Microsoft Visual Studio Remote Debugger named '192.168.1.139:8116'. Connection request was rejected by the remote debugger. Ensure that the remote debugger is running in 'Windows Authentication' mode.
The following screenshot of the IoT Device Portal shows both the IP and Port for Remote Debug and the fact that my app (echo.exe) is running:
I've tried running the remote debugger both with and without the "Run as DefaultAccount" option checked, but this seems to make no difference.
I've also checked the firewall settings on my dev PC to ensure that it is not blocking traffic (I am connecting over the Private network)
Although the error message warns about Windows Authentication Mode, I can find no such setting for the remote debugger. Any help in getting the Remote Debugger attached and operational would be gratefully received.
You may need to select the connection type to "Remote" instead of "Default".
It works for me. You can have a try and feel free let me know if there is any problem.
One thing that I think it could help is when deploying the app to the Remote Machine and you are presented the ‘Remote Connections’ dialog you can choose there what type of authentication you want. One of the options is Windows Authentication. Try deploying and running the app like that and then the Remote Debugger should work.
In your VS Studio Project Properties -> Debug Tab -> Authentication Mode: Window Authentication
I have simple one Windows Forms project with one Main form in Visual Studio 2013 Update 4, on my dev Windows 8.1 Pro PC. I also have second computer (name: REMOTEPC) with Windows 8.1 Pro and installed Visual Studio Remote Debugging Monitor 2013 Update 4. I have configured Windows Authentication and firewall settings. I have configured project properties for Debug to use remote machine to REMOTEPC:4018 and in logs I see that user REMOTEPC\username connected. I use same local and remote paths (C:\proj\bin\debug\myprogram.exe) and have manually copied all files from directory.
Now I got error:
Error while trying to run project: Unable to start program (C:\proj\bin\debug\myprogram.exe). The MSCSMON.EXE does not appear to be running on the remote computer.
As I understand it needs only one TCP 4018 port and can not find a mistake. I have read MSDN info about this, but can not figure out why its not working. Is the remote debugging for Windows Forms or WPF possible at all ?
The solution is to use to configure firewall / port forwarding if needed, for both TCP 4018 and TCP 4019. I was missing one port (4019) and now it works without a problem.
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.
Please excuse my ignorance, I am mainly a Java developer and a bit unfamiliar with Visual Studio and the details of some of the debugging process.
I am creating an application (WPF and Console) in C# that is being developed on my workstation but I need to run/debug the application on another remote machine. Is there a way that I can just hit "Debug" from Visual Studio 2010 and have it emulate a run from the target machine? I need to do this because of local file directory access on the remote machine.
I have looked into remote debugging, but I think I am on the wrong track, as remote debugging just seems to use another machine to run the debugger, not the process itself.
Any information is greatly appreciated!
You will simply attach to process of the running application, for detailed explanation you should take a look at article
Remote Debugging with Visual Studio 2010
you cannot, but you can remote debug and attach to the app running on the remote machine, you will need the remote debugging tools installed on the remote machine
running (F5) on a remote machine, directly from within VS is possible in Dev11, however