Introduction to Remote Debugging

The Visual Studio remote debugging components allow you to debug managed and unmanaged programs running on a machine that doesn't have the full installation of Visual Studio. This means that you can use Visual Studio on your development machine to debug components running on a remote machine such as a database server, Web server, or middle- tier application server.

Probably the most common use for remote debugging is when you're investigating a production problem. The average pointy-haired boss tends to be fairly paranoid about upsetting a production machine by installing a copy of Visual Studio on it, never mind the licensing issues that this involves. With remote debugging, you can keep Visual Studio and your application's source code on your development machine and install just the remote debugging components on the production machine. You can even go further and use the remote debugging components from a network share that's accessible from the production machine, thereby leaving your production environment in an almost pristine state.

You can use the same remote debugging techniques to investigate components running on development Web servers and application servers. The only caveat with a Web server is that IIS 5.0 supports just a single developer debugging at any one time, but IIS 6.0 overcomes this restriction (for more information about this, please see Chapter 9). In addition to the debugging of Web and application servers, you can also use remote debugging to debug SQL Server stored procedures running on a remote development or production database server.

It's not unusual for a developer to have problems when running and testing a colleague's component. You can use remote debugging to reach across to your colleague's machine and see exactly why he or she is having a problem with your component. If your colleague has Visual Studio installed, you don't even need to install the remote debugging components because they're installed automatically with Visual Studio. If your colleague hasn't installed Visual Studio, the remote debugging components can be installed on his or her machine by creating a network share on your machine and connecting to that share from your colleague's machine to perform the remote debugging installation.

Finally, and if you're really ambitious, you can use remote debugging across the Internet to investigate a client's problems with your software. This requires your client's cooperation, in that the client will temporarily have to open a hole in his or her Internet firewall to allow you to use Terminal Services to log into a machine in his or her network. In addition, your client will need to install Visual Studio on the machine that you're logging into with Terminal Services. This workaround is necessary because normal remote debugging doesn't work across Windows domains that don't have two-way trust. But once your client has installed Visual Studio on one of his or her machines, you can then use Terminal Services across the Internet to reach over to that machine, and then use normal remote debugging to jump onto any other of your client's machines for problem investigation. I discuss this further in the next section.