Debugging with Visual Studio, SharePoint, and Workflow

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 21^st 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.

Ten Issues and Resolutions for SharePoint Workflow

I’ve been meaning to get caught up on blogging for a while now but it seems like the need to be productive has overwhelmed the desire to get some of the challenges I’ve run into written down.  As it happens, however, I just got derailed by another issue, so it’s a perfect time to reflect upon some of the issues I found, and resolutions to them. (I’ll post the resolution to my latest issue sometime after I get it.)

• Issue: If you define a field <Field> with a ReadOnly attribute it doesn’t show up in the interface anywhere.
  Resolution: Set the field as ReadOnly in the <ContentType> <FieldRef> instead.  This allows it to appear. (Thanks Manish.)
• Issue: If you make changes to a <Field> definition it isn’t seen.
  Resolution: Add the DisplaceOnUpgrade=”TRUE” attribute to force the updates to be seen.
• Issue: Changes made to a content type aren’t seen by a list the content type was already associated with.
  Resolution: Remove and reassociate the content type with the list from the user interface.  (Sorry, I don’t have a programmatic resolution to this one.)
• Issue: Receive an exception “SPException: This task is currently locked by a running workflow and cannot be edited.” while trying to edit a task.
  Resolution: Workflow locks the tasks it creates – except from within the context of an UpdateTask, an OnTaskChanged, CompleteTask, or RollBackTask activity.  If you’re trying to modify the workflow from the web/user interface, make sure that the workflow is in a listen activity listening for a OnTaskChanged event.  If you’re in the workflow itself you’ll need to do it from an UpdateTask activity.
• Issue: My changes to a task inside an UpdateTask activity aren’t recognized.
  Resolution: Use the SPWorkflowTaskProperties object attached to UpdateTask to update the task properties.  These will be written out during UpdateTask and since they’re not synchronized to the list item, they will be out of sync and overwrite your changes.
• Issue: Some of the fields in my task are getting overwritten when I do an UpdateTask in the workflow.
  Resolution: UpdateTask writes out whatever is in the SPWorkflowTaskProperties – including extended properties – and since these are not synchronized with the task itself – may be out of date.  Make sure that you write out the correct values to SPWorkflowTaskProperties so they are updated correctly.
• Issue: I’m using SPListItem.SystemUpdate() and the workflow OnTaskChangedActivity fires.
  Resolution: I don’t know.  Even SystemUpdate() seems to trigger the OnTaskChangedActivity.
• Issue: Fields that are in the task list aren’t being displayed in the edit or display forms for the workflow tasks created.
  Resolution: Workflow tasks are designed to work with a specific content type.  This content type is added to the task list – even if managing content types is turned off.  The display form and edit form are the forms associated with the content type.  To get more fields to be displayed and to be editable define your own content type.  Then either specify the TaskListContentTypeID attribute of the <Workflow> node in the element XML file or use the CreateTaskWithContentType rather than CreateTask activity.
• Issue: My workflow is completing but isn’t going through the entire path – or my fault handler.
  Resolution: In my particular case, I had an issue with serialization where one of the properties of my custom activity (to send email) wasn’t serializable.  However, the reported exception wasn’t the actual exception being raised and it was recorded in the ULS.  Verify that your custom activities can serialize correctly.
• Issue: SPWorkflowTaskProperties.ExtendedProperties aren’t populating the fields in my task.
  Resolution: In my particular case, I had somehow managed to get multiple fields in the task list with the same name.  (I’m not sure how precisely.)  I deleted the extra fields and CreateTask started populating the fields in the task.