Debugging is an art form. Much like regular art it’s influenced by the tools at our disposal. Photography wasn’t something that Da Vinci was into probably because photography didn’t exist. He used stone and chisel – canvas and brush – like I use a mouse and keyboard. (Ok, so he’s a bit more of an artisan.)
Debugging with SharePoint and workflow is like this. You have to use the tools you have at hand. As developers we’ve become spoiled by the tools we have. I start my debugging most of the time by turning on first chance exceptions and F5 (run with debugging.) If I make it through the application without generating exceptions I’ll generally do step-by-step debugging of critical areas. I depend upon first chance exceptions to speed my development time.
Unfortunately, trying this with SharePoint Workflow development doesn’t work. The first chance exceptions are simply not raised to the debugger. That’s disappointing but not the end of the world. I wrote code for a VAX system 15 years ago and our most powerful debugging tool besides detailed code walkthroughs was the print statement. (A detailed code walkthrough is where you try to run the program yourself as if you were the computer. Not a lot of fun but it’s effective.)
To make things just a tad more challenging the step over (F10) and step into (F11) don’t work all the time nor as you might expect in Visual Studio. First, you can’t step over an activity that causes the workflow to serialize. It makes sense since the thread you’re working with goes away but it’s also annoying. Fortunately you can just set a breakpoint on the next activity to get nearly the same effect. Also, F10 is a step over but it doesn’t step over containers in the activity it steps into the container and its activities. It won’t step into the code behind the activity itself so there is some help there.
Of course, the breakpoint idea works well when breakpoints fire but I’ve seen more than one occasion where the breakpoint doesn’t get fired either. That might cause one to ask how do I debug then? The answer … LogToWorkflowHistoryList … the 21st century version of PRINT. You can insert them into your workflow – and into your fault handlers and use that to see what is happening in the workflow. It is not sexy but it works.
One limitation of LogToWorkflowHistoryList is that the HistoryDescription is limited to 256 characters. If you run into this you can use the OtherData property. Although it’s not displayed by default, you can see the values. You can use it for larger strings. How do you see it? Point your browser directly to the hidden Workflow History List. If your server is http://localhost and if your Workflow History List is named Workflow History List you should be able to get to the list by entering http://localhost/lists/Workflow+History+List This will display the OtherData field on the page – it’s great for use with a fault handler because you can dump the entire exception.ToString() to the .OtherData property to see the exception and stack trace.
So while the tools you’re used to don’t work … that doesn’t mean you can’t find a way to debug SharePoint Workflows.