Debugging in Workflow 4.0

Visual Studio 2010 Beta1 is out and includes the new Windows Workflow Foundation (WF 4). This is something we have been working on for last 18 months and specifically I have been responsible for the Debugging experience of Workflows.

As in Workflow 3.0, we continue to provide the debugging experience for workflows through the designer surface. In addition, we continue to make improvements over the existing 3.0 workflow debugging experience. Some of the enhancements include:

The underlying representation of the graphical form of the Workflows we see on the designer surface is Xaml. This Xaml representation can be viewed by right-clicking on the workflow file (.xaml) in the solution explorer and selecting ‘View Code’. Though users can author the workflows entirely through the designer, it is possible that developers would like to view the Xaml representation and directly edit the workflow through this view. For such purposes, we now allow the users to seamlessly debug workflows through the designer and the Xaml view.

Below is a workflow which has a breakpoint set through F9 or through the activity's context menu on the root activity. If we F5 this project, workflow execution will break on the root activity as follows:

At this point, the developer may decide to move to the Xaml view of the workflow through the ‘View Code’ option.

This will open the Xaml view and you can see that the root Sequence activity still has the debug adornment in the Xaml view.

You can remove/set the breakpoints on the Xaml view, and debug through the Xaml view. Or you can switch back to the designer view by double clicking on the workflow file in the solution explorer and debug on the designer surface. Pretty seamless!

On switching to the designer surface, you will notice that we have the bread crumb view of the parent composite activity.

In addition to the seamless debugging, the other features like Locals, Call Stack, Watch, Immediate and some breakpoint window support are provided as well. The traditional F5/F10/F11 mechanism work as expected providing step over and step into functionality. If the activities are implemented in code, the user can debug into the code by setting a breakpoint on the Execute method defined for the activity in C#/VB.

We also support ‘Attach to Process’ workflow debugging which can be leverage when debugging workflow services hosted in IIS.

Last but not least, we have made DebugService public in WF 4 so that users can extend the behavior for creating custom applications like Monitoring, Simulation and provide debugging even in the case of the re-hosted workflow designer. I will cover this aspect in my next blog post.

Thanks,

Kushal.

Comments

• Anonymous
  June 01, 2009
  PingBack from http://microsoft-sharepoint.simplynetdev.com/debugging-in-workflow-40/

• Anonymous
  June 01, 2009
  Continuing on the theme of Workflow 4.0 blog, this blog post talks about the enhancements and features

• Anonymous
  July 16, 2009
  what is the story around debugging code activities?

• Anonymous
  December 01, 2009
  Hi Kushal, Would you be able to provide more information on debugging in the rehosted designer?  I understand you may have given a talk at PDC, but I wasn't able to attend. Thanks, Notre

• Anonymous
  February 18, 2010
  Hey Kushals Do you think that you could include debugging workflows in a rehosted designer based on data captured in AppFabric? Matthew