Difficulty getting Visual Studio 2010 to attach to remote processes

It's been years since I've had such a hard time getting something to work. I'm at home, on subnet 192.168.50.nnn. I VPN'd in to XYZ company office machines that are on subnet 192.168.40.nnn, domain XYZ. I can ping the remote machines, I can net map their drives and copy files back and forth, but for the life of me I cannot remotely debug a C# program running on a machine called R (ipaddr 192.168.40.100, Windows Server 2003, IIS-6) from Visual Studio 2010 on my laptop (ipaddr 192.168.50.10, Windows 7, user XYZ\username, machine name L). I've read every MSDN article I can find, I've checked firewall settings, I unblocked port 135, I have the same user na开发者_如何学Cme and password on the two machines, I've tried running msvsmon.exe on R as a service and as an application (advertising itself as username@R), msvsmon has sufficient privileges, but I just cannot attach to any process on R. I can't even get a list of processes on R to show up. If I could pay someone to fix the problem I would, but I wouldn't pay a dime until I saw it working.

[Note: The IP addresses above are illustrative only, not the real values.]

---

I had a similar problem and my setup looked like this:

Client: Windows 7 x64 on a private subnet 192.168.1.x. Running Visual Studio 2010
Server: Windows 2008 R2 Standard SP1 with a public IP-address

Both client and server where stand alone. I.e. no domains, just workgroups.

VPN connection from client to the server and when I connected the client got the ip 192.168.0.131 and the server 192.168.0.130.

Turned off all firewalls etc. for the VPN connection, created identical users on the client and the server and identical password.

Ping, network shares, etc. working with no problems over the VPN connection. But I got the same error message from Visual Studio: "The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer."

The solution for me was to change the workgroup name on the client to the same one as the server. After that, everything worked perfectly.

---

You need to be authenticate on the same domain (or at least there be a trust relationship between the two) as the remote machine. Is the local machine attached to the domain on the other side of the VPN? If not, you cannot debug managed code using remote debugging.