Step Into Remote Code with VS Remote Debugging

If you’ve got a development setup which includes webservices which you’ve written and deployed to a local development server, and you’re debugging front-end apps which use these webservices, then you may well want to take advantages of the services of the Visual Studio Remote Debugger.

Essentially it allows you to step into the code running on the dev server – in this case the webservices and see what’s happening without having to go back to the original project, fire it up locally, re-point the front-end application configs etc. It saves a lot of time!

At the heart of the thing is the Remote Debugging Monitor: essentially a program that sits on the remote machine and listens to requests that Visual Studio sends for debug access.

There’s a couple of security things to be aware of, depending on your setup. Obviously, once you fire up the Remote Debugging Monitor it will accept requests from anywhere, unless you’re clever with permissions. You can tie it down to local network use only, but your firewalls are already doing that, right? For many people, that’s probably good enough.

Anyway, to install, you can find the installer on the Visual Studio install DVD, the /RemoteDebugger/ folder. There’s a fairly simple wizard that steps you through first installing it, then configuring it. You get the choice of using it as an application you can start and quit, or a service you can fire and forget.

Once it’s installed, for me it was just a case of going back to the front-end code and trying to step-into a call I knew was hosted remotely. There’s a warning about attaching to the debugger, a short pause, then a prompt about the code file.

Basically (I think) – Visual Studio knows the DLL you want to debug, but it can’t find the code on your machine (usually because remotely the location is different, such as under /inetpub blah blah). The location on the remote machine is shown at the top of the dialog box.

You then provide the location of the source files on your machine, wait a second, and then your step-in will be honoured. You can step in and out, set breakpoints, move the flow cursor around just as you would with local code.

Additionally, Visual Studio seems to remember your choice of local code location, so you don’t have to do it next time.

If you need it, you can get a bit more information from MSDN here: http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx

This is a really valuable feature which I was previously unaware of. For anyone who writes front-end applications that communicate with code elsewhere in their stack, it’s a brilliant way of saving time and effort when debugging.