Difficulty getting Visual Studio 2010 to connect to remote processes

Question

Years passed when it was so hard for me to work. I am at home on the 192.168.50.nnn subnet. I connected to the XYZ corporate office machines located on the 192.168.40.nnn subnet, the XYZ domain. I can ping remote computers, I can display their disks and copy files back and forth, but for life I can’t 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 read every MSDN article I can find, I checked the firewall settings, I unblocked port 135, I have the same username and password on two machines, I tried running msvsmon.exe on R as a service and as an application (advertising by itself like username@R ), msvsmon has sufficient privileges, but I just can't connect to any process on R I can’t even get a list of processes on R to display. If I could pay someone to fix this problem, I would not pay a dime until I saw that it works.

[Note. The IP addresses above are for illustrative purposes only and not valid.]

Answer 1

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

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

Both client and server where they are autonomous. That is, there are no domains, just workgroups.

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

Disabled all firewalls, etc. for a VPN connection, created identical users on the client and server and the same password.

Ping, network resources, etc., working without problems on a VPN connection. But I got the same error message from Visual Studio: "The remote Visual Studio debugger on the target computer cannot connect to this computer. The firewall may prevent the exchange of data through DCOM to the local computer."

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

Answer 2

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