Remote Debugging Transports

VS7.1 shipped three different ways of doing remote debugging. We called these 'transports'. Unfortunately, the naming of the different transports was fairly poor. The good news is that we have a much better story for this in Whidbey. Anyway, let's go through the transports:

Option #1 -> 'Default' transport. Default transport supports local and remote debugging for Script, T-SQL, Native, and managed code. All managed projects (C#/VB/J#) always use default transport. For VC projects, you get default transport when you have 'Connection' set to 'Local' or 'Remote via DCOM'. In the processes dialog, you are using 'Default' transport whenever the Transport drop down is set to default.

For managed debugging, default transport is the only option. Managed remote debugging depends on marshalling a very large list of different COM interfaces, since we weren't about to write our own custom marshalers, managed debugging requires DCOM, and so you are stuck with default transport.

For native debugging, you can use default transport, but it doesn't buy you much. In VS7.1, default transport really uses named pipe transport. In VS7.0, default transport really uses TCP/IP transport. The only DCOM part of pre-whidbey native debugging is that we use DCOM to start msvcmon.exe, which then listens on a socket or pipe.

The problem with default transport is that it requires the remote debugging components to be installed on the server. Since we didn't have a separate remote debugging install, getting the remote debugging components on the server can be a pain. The other problem with default transport is that there is no flexibity for controlling the environment or user context of the worker process. In Whidbey this is much better.

Option #2 -> 'Named Pipe (native only)' transport. Named pipe transport only supports native debugging. For VC projects, you get named pipe transport when you have 'Connection' set to 'Remove via Named Pipe'. It is relatively secure because we use NT authentication (NTLM). However, named pipe (SMB) traffic is usually not encrypted, so you are susceptible to attacks where a hacker reads or modifies the data. SMB is also relatively slow.

Option #3 -> No Auth ('TCP/IP (native only)') transport. No auth transport also only supports native debugging. For VC projects, you get no auth transport when you have 'Connection' set to 'Remove via TCP/IP'. In the processes dialog, this is called 'TCP/IP (native only)'. In Whidbey, we renamed this to 'Remote (Native only with no authentication)', which is great since its original name was so incomprehensible. No auth transport only makes sense when you are on some small network which is behind a firewall. It is useful when you need to debug across domains, to Win 9x, or on machines where NTLM just seems to be broken. Otherwise, I would use one of the more secure transports.

For Whidbey, we have made some big changes here. We got rid of the named pipe transport. Default transport always uses encryption on NT, and always uses authentication on Win 9x (even for native debugging). Default transport no longer requires files to be installed on the server machine, just run msvsmon.exe (sequel to msvcmon.exe) off a file share.