Original URL http://www.codeproject.com/Articles/146838/Remote-debugging-with-Visual-Studio-2010
you may also need to set up window firewall for this. see URL https://msdn.microsoft.com/en-us/library/ee126350(v=vs.100).aspx
I've recently needed to remotely debug a .NET desktop application with Visual Studio 2010. After having read the MSDN documentation on this subject, I still missed some information. I hope that this post will fill some of these gaps and will help you configure and run the remote debugging tools.
Let’s first start with a definition of parts involved in the debugging process:
- host – is a machine on which Visual Studio is installed and on which you control the debugging process
- remote computer – is a machine on which the debuggee is run
Since the debugging process is wholly controlled from the host, there must be a listener on the remote computer that executes commands sent from Visual Studio. This listener is called Remote Debugging Monitor (msvsmon.exe). There are two possible ways to install it – you can either download and run the setup package from Microsoft or copy all the necessary files from C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger (path on my 64-bit Win7). A caveat here: If your host is x86 machine, then you have no choice but x86 package for your remote computer – there is no way you can debug a 64-bit process in a 32-bit debugger. Though you can debug 32-bit process in a 64-bit debugger.
Next step (the most boring and error prone in my opinion) is a network setup. Ideally Visual Studio and Remote Debugging Monitor should take care of the Windows Firewall settings after you run them with the elevated privileges, but life is life and you might need to get your hands dirty. Fortunately the manual configuration process is pretty well explained on MSDN sites for WinXP, Vista and Win7. The next important thing is security. You can either perform debugging in “NoAuthentication” mode (which is of course less secure) or in Windows Authentication mode. Unfortunately Windows Authentication mode requires the same account to be setup on the host and the remote computer – both usernames and passwords must be the same. If it’s a problem for you, then you are left with the “NoAuthentication” mode in which you take a risk of allowing all people to access your debugging monitor.
Having finished the configuration part, we may finally start the debugging process. Begin with starting msvsmon.exe (Remote Debugging Monitor) on the remote computer – it will communicate with Visual Studio running on the host. Let’s assume that our application is named RemoteControl.exe and is written in C#. First, we need to deploy it on the remote computer, for example into the C:\Users\concept\Desktop\RemoteControl folder (remember to copy also all the pdb files and the assemblies required by the main application). We can now either start the application under the debugger or attach the debugger to the already running process. Let’s start with the first scenario. If you have access to the application solution folder and to all the project files, then you can start the remote debugging by modifying the start project properties page:
If you don’t have access to the application solution, then you need to use the application EXE file. From File menu choose Open->Project/Solution… and find the EXE file for your application. Select the newly opened project and choose properties. Fill the page with following values:
Attaching to the already started process is fairly simple: From the Debug menu, choose Attach to process…. If you are debugging in the Windows Authentication mode, set the Transport box to Default. In Qualifier field, type name of your Remote Debugging Monitor session. Usually it is your user name + @ + the remote computer name, for example Sebastian@REMOTE-PC (the session name is also displayed in the listbox after you start the msvsmon.exe).
Finally, a few words about the debugging process. Unfortunately the debugging symbol configuration differs depending on the chosen debugging engine (native, managed, mixed). When using managed debugging engine symbols must be accessible on the remote computer (so you need to deploy your application with all pdb files and set_NT_SYMBOL_PATH variable on the remote computer for .NET Framework debugging symbols). When using native debugging engine symbols are loaded from the host machine (so you must include the directory with all pdb files for your application into the Visual Studio symbols search path – Tools->Options->Debugging->Symbols). Interestingly, source files are always loaded from the host machine (in case that you don’t use any kind of source server). To summarize: remember to always choose the managed engine for your .NET applications that don’t have any interop parts. The native engine requires much more information (like symbols for all native libraries) and provides you with capabilities that are usually not necessary in debugging pure .NET application.
I haven’t touched the subject of the web applications remote debugging and running Remote Debugging Monitor as a service. Leave a comment if you wish such a post to appear in the future.
