- #Visual studio 2017 remote debugger how to#
- #Visual studio 2017 remote debugger code#
- #Visual studio 2017 remote debugger password#
Runas /user: localcomputernameusername “ devenv.exe” With the remote debugging stub waiting for connections, you’ll need to start Visual Studio on the local machine with the account as well. Runas /user: remotecomputernameusername “ msvsmon.exe” On the remote machine, you’ll need to login with the new account or if you’re logging in with a different account, use RUNAS.EXE to fire up MSVSMON.EXE like the following. With the same computer accounts on both machines account life is easy. Net localgroup administrators remotecomputername username /add
#Visual studio 2017 remote debugger password#
Obviously you’ll be using the same user name and password you entered on the local machine. On the machine where your application runs, called the remote machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following commands. That creates the user account you’re going to use for Visual Studio.
Yes, you can do the same through the GUI but this is much faster. On the machine where Visual Studio runs, called the local machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following command. As long as the username and password on the both machines is the same, DCOM can make the connection. DCOM first attempts to make the connection with machineusername account and if that does not work, it falls back to the username using the hashed password. The big trick is to do your remote debugging with local machine accounts. The issue with DCOM is there’s a security ramification where an account one domain does not have rights on the other workgroup or domain. If you don’t you should read the documentation to understand what I’m talking about here.
#Visual studio 2017 remote debugger how to#
Finally, I’m assuming you know how to set up remote debugging for the supported same domain/workgroup scenarios. Again, your mileage may vary and your network admins may not let you perform the following so you’re on your own with these steps.
#Visual studio 2017 remote debugger code#
NET code with pure TCP/IP this will get you at least started. It’s not an ideal solution but until Microsoft allows us to debug. When I have to remote debug across domain/workgroup boundaries, here’s what works for me. NET remote debugging relies on DCOM, which as a transport protocol does not jump workgroup or domain boundaries. The problem comes in when you need to do remote debugging for managed code across domains or workgroups. It also works dreamily if you’re doing straight native C++ where you can use the TCP/IP as the debugging transport.
Remote debugging in Visual Studio works great if both machines are on the same domain and/or workgroup.
0 kommentar(er)
