Remote Debugging in Visual Studio is a wonderful feature, especially during the later stages of testing and deployment, and even (if all else fails) when in production, but getting it to work is rarely smooth. Everything is fine if both the computer running VS and the one running the application are in the same domain, but when they aren’t, things start to break, fast. I
So for those stuck debugging remote applications in different domains, here’s a quick guide to east the pain.
- On the the remote machine, install the Visual Studio Remote Debugging package, which comes with the version of Visual Studio you’re using.
- On the remote machine, create a new local user account. Give it the exact same name and password that you use on your development machine.
If you’re developing when logged into MYCORPDOMAIN\MyUserName, with password MYPASS123, you wil have to create a local user REMOTEMACHINE\MyUserName with the same password. It doesn’t matter that the domains are different and there’s no trust relationship and so forth. Just have them be the same username and password.
- Give REMOTEMACHINE\MyUserName permissions. Administrator permissions is the safest, though you should be able to get it to work with a more restricted group, but I haven’t checked it yet.
- Run the application you want to debug using the MyUserName credentials. In Windows 7, this means using Shift-Rightclick and choosing Run As Different User. For Vista, there’s a shell extension to enable it.
- Run the Remote Debugging program, again under MyUserName credentials, same as above. The Remote Debugger will start with a new session named MyUserName@REMOTEMACHINE.
- Copy the remote debugging session name from the remote machine (you can copy it via the Tools –> Options menu).
- In your development machine, open Visual Studio, and go to Debug –> Attach to Process.
- In the Attack to Process screen, paste the remote debugging session name into the Qualifier textbox (the second one from the top).
- Voila! You are now debugging remotely!