By far the most painful part I have come across is the dreaded delay activity never waking up problem. This occurs when you place a delayActivity object in your workflow in order to wait for something to happen (for example in a while loop). This is pretty fundamental stuff in a workflow, so you would expect this to be a basic requiredment, but for some reason SharePoint has a HUGE flaw in this department: when you are developing your workflows, they seem to get stuck in the delay and never wake up!
|A WWF DelayActivity in a while loop|
|Workflow history - it never wakes up after delay :(|
After much head scratching, I have found a solution. The delayActivity passes control to the SharePoint Services Timer (OWSTIMER.EXE), and this gets confused if you redeploy the wrokflow.
To fix, follow these instructions.
First run this command on your farm:
(note apparently doesn’t like being anything but 5 minutes! )
I rebooted my dev box after this but this is probably not required.
The key part is that now provided I restart the Microsoft Sharepoint Timer service between deploys, it actually completes a delay! So remember to recycle the "Sharepoint 2010 Timer" service before you depoly a new version of the workflow to the farm.
Note that this was supposedly a bug fixed in 2007 that is back in 2010. See this hotfix for 2007 systems: http://www.microsoft.com/en-us/download/details.aspx?id=21066
To debug any code that runs after a delay, you have to attach Visual Studio to the timer service (owstimer.exe), not the w3w process. I do this by switching off "auto retract after debugging" in the "Sharepoint" page of the project's properties file and manually attaching to the OWSTIMER.EXE process.