Remote Debugging Team Environment ABSTRACT

Remote Debugging ends up being very useful in the Module Development Process, especially if you are not going to be doing the development against the IIS on your own machine.

In our environment, we have built a 3-tier development lifecycle strategy. Our DNN portal is being used as a strong application platform for a SOA-based integration. We are leveraging the DNN architecture as an application framework against Oracle Applications, in particular PeopleSoft Contributor Relations.

3-Tier Strategy

We develop against multiple instances of DNN, and then move our development projects into a test environment, before finally making the step into production. The test environment is refreshed by production very often, so that the upgrade path to test can very easily be duplicated into production. The sandboxes are refreshed on a as-needed basis.

Remote Debugging

Most, if not all of the debugging occurs in the sandboxed environments. Each developer on our team is assigned a sandbox and a database for that sandbox. All of the sandboxes for development are on the same 2008 server running under a different user for each one.

Microsoft packages a remote debugger with the professional version of Visual Studio 2008. You can copy this installation directory to the server and run it, exposes the processes of the server to the VS client. There are good tutorials on how to do this, and I won't get into details here.

Once the remote debugger is up, one simply opens the Tools > Attach to Process option in Visual Studio, and gives the correct servername. You will see w3wp.exe in the process list (if not, the site has not been used in a while, and your worker process has timed out. Just browse to the portal in your favorite interent browser and refresh the list in Visual Studio.) If you have set your Virtual Directories to run their applications (app pools) as different users, you will notice that the one that correlates to your application pool. Attach to that process and you will be set.

Once you have attached, you are into the debug. You should be able to open up any file location that will allow you to attach a valid breakpoint, and step into the process. You can also access other options such as exceptions, SQL and T-SQL debugging, Silverlight, and more.

Happy debugging..

Oh, and when you are done.. detach from the process.. people get frustrated when their code doesn't run..