I try to run the Visual Studio Remote Debugger in a Windows Container on Windows Server 2016 TP4. Since it runs inside a conta
Did you try to "hardcode" the hostname using the msvsmon /hostname option?
According to the msvsmon documentation: "/hostname hostname_value Instructs the remote debugger to listen on the network using the specified hostname value, or IP address value. On a computer with multiple network cards, or with multiple assigned DNS host names, this option can be used to restrict which of these will allow remote debugging. For example, a server may have an internet facing address, and an internal address. By using '/hostname private_ip_address', remote debugging will not be available through the internet facing address."
I found this sequence to work:
PS C:\> start-service msvsmon150
PS C:\Program Files\Microsoft Visual Studio 15.0\Common7\IDE\Remote Debugger\x64> .\msvsmon /noauth /anyuser /silent
The start-Service command will fart out an error about how the service can not start when running in a Windows 10 hosted Windows container. However, after entering the second command, the ports show up as blocked in netstat -ab and Visual Studio 2017 can sniff the debugger unit.
To debug you'll need to install the remote tools into the image, run the container as per normal, and then start the remote debugger using docker exec
.
The command line is as follows:
docker exec -it <container id/name> "C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /nostatus /silent /noauth /anyuser /nosecuritywarn
I've got more detail in a blog post, and yes, turning off auth on your local dev machine does carry some risk (no matter how small) but this should at least give you an idea of how to do it. You can always tweak the command line options to get it working the way you want.
Okay, throwing out the really obvious here. From your post, the command
".\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF"
will just print that exact same string in powershell. It doesn't actually start the debugger. The echo output shows this. (I might be reading too much into this)
So /nofirewallwarn
only suppresses the blocked by firewall warning (YMMV), and doesn't actually get through the firewall. Have you run it with /prepcomputer
first?
Have you tried /anyuser
to bypass auth and allow just TCP to work?
Is msvsmon actually bound to the right network interface? Sometimes, being bound to the loopback adapter means that it can only be reachable locally. When you netstat
does it show listening on all interfaces (0.0.0.0
)?
Have you tried running it as a service with the /service
option?
There might be some more gotchas, though. I've usually had a tough time getting it to work in the field.