One bug, two developers: Collaborative debugging is now a reality in Visual Studio 2010

Quite often, one or more developers need to collaborate on a bug to figure out the root cause of the problem. This collaboration is typically done using tools like email, bug tracking system (e.g. TFS) or if the developers are collocated, they might work on the bug together in one of their offices. Here is what the typical workflow looks like:

Collaborting on a bug 

In the workflow above, when Developer 1 hands the bug over to Developer 2, there is a lot of context and information that is left out and what usually happens is that Developer 2 restarts debugging the same issue to figure out the root cause. Basically, Developer 2 ends up doing a lot of redundant work that Developer 1 has already done. Ideally, Developer 2 should be able to leverage the investigation work that was done by Developer 1 and just continue the debugging session.

In Visual Studio 2010, using two new features , i.e. Breakpoint Import/Export and DataTips Import/Export allows Developer 1 to hand off the debugging session to Developer 2 so that Developer 2 can just pick up where Developer 1 left off.

Let's go through an example to see how this collaboration works. In this example, Developer 1 is investigating a bug in the Tailspin Toys e-commerce sample application. He is trying to figure out why the Shopping Cart isn't updated when the user adds the same toy to the cart. After debugging the problem in Visual Studio, Developer 1 discovers that the bug is in a method (AdjustQuantity) that is in a component (Tailspin.Model) owned by Developer 2. The screenshot below shows where Developer 1 thinks the bug is.

AdjustQuantity bug

At this point, Developer 1 wants to give this bug to Developer 2. However, rather than have Developer 2 do all the work to reproduce the bug, Developer 1 captures a couple of crucial pieces of information and sends them along with the bug to Developer 2. In a sense, Developer shares his debugging environment with Developer 2. First, Developer 1 exports his current breakpoint by right-clicking on the breakpoint in the editor and selecting the "Export…" command, as shown below. By exporting the breakpoint, Developer 2 can now easily figure out where to start investigating the bug.

Export Breakpoint context menu

The exported breakpoint file is shown below.

Exported Breakpoint File

The next piece of information that Developer 1 wants to share with Developer 2 is what information Developer 2 should look at when debugging the problem. In order to do that, Developer 1 first "pins" the variable that he thinks is causing the bug to the editor, as shown below.

Variable pinned to the editor

After pinning the variable to the editor, Developer 1 exports the pinned variable, by selecting the Debug –> Export DataTips… command. The exported DataTips file is shown below.

Exported DataTips

Now, instead of Developer 2 restarting the investigation, he can continue where Developer 1 left off by importing the debugging environment. The new workflow is shown below.

Collaborative Debugging

To import the debugging environment, Developer 2 can import the DataTips file from Debug –> Import DataTips. The exported breakpoints can be imported from the Breakpoints window, as shown below.

Import Breakpoints

After importing both the breakpoint and the DataTips, Developer 2 can simply continue his investigation by pressing F5. The debugger will now stop at the breakpoint that Developer 1 exported and will show the variable as well. It will even show the comment that Developer 1 wanted to pass onto Developer 2. This is shown below.

Developer 2 Debugging View

If you have any feedback or suggestions on this feature or have any ideas on how to better collaborate when debugging, feel free to leave me a comment.

Habib Heydarian.