When I was experimenting with this, I wanted to use Reflector VSPro to step into the. Most importantly, if the symbol path is set on the host machine, it will still look for files on the symbol path, BUT they will be searched for in those locations on the target machine. NET applications, even though the debugger is running on the host machine, it will look for pdb files on the target machine. So the target machine is now available for remote debugging, but we’re still not ready yet. Search location for pdb files and sources This is useful for debugging connection failures. When the Debugging Monitor is running, it displays a view of the connections as they come in, as shown below. This executable is a DCOM server that handles the requests from remote clients, attaching to the relevant processes and getting data from them. \program files\microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger The way to set this up is to run the appropriate version of msvsmon.exe, which you can find in the architecture-specific subdirectory: The host machine talks to the target machine via DCOM in order to get the data it needs for debugging the application. Of course, it isn’t really quite that easy… Making the target machine available for remote debuggingīefore you can get started, the target machine has to make itself available for remote debugging. It would be nice if all that was necessary was to select Debug, Attach to Process in Visual Studio on the host machine, and then enter the name of the target machine. Recently, someone pointed out to me that Visual Studio has an alternative for debugging remote applications, which ought to make it a lot easier to debug problems in.
#VISUAL STUDIO REMOTE DEBUGGING IS NOT SUPPORTED INSTALL#
Using some of the modern support technologies such as NTRsupport, this is fairly easy to do, and by using WinDbg and the SOS Debugging Extension it is possible to install very little on the target machine while still being able to get enough data to diagnose the problem. In those scenarios, it would be nice get access to the customer’s machine. Still, it’s impossible to test all possible configurations, and so all too often bugs turn up. Build systems try to ensure that the hidden dependencies are brought to the surface, and large collections of untainted virtual machines allow you to quickly test an application in a clean room environment. Of course, it’s not really quite like that. Then, you’re totally disappointed when you copy the executable to another machine and it crashes. You’ve configured your machine the way you like it, you’ve installed all manner of add-ins into Visual Studio, you’ve added a number of seemingly random assemblies to your global assembly cache. Remote Debugging in Visual Studio: Squashing Bugs in their Native Environment - Simple Talk Skip to contentĪs a developer, you get to write your application in a little sandbox that’s isolated from the real world.
0 kommentar(er)
