Recently saw this question in the MSDN Workflow Forum
Many users of Workflow in .NET 3.5 took advantage of the StateMachineWorkflowInstance class to determine what state a workflow is in, and also to force it to a new state. Some people use this class as a way to enable/disable controls in the UI of an application.
I recall a conversation I had with some developers from a bank that wrote an application for their tellers that used this feature. One problem they had was that when the UI used StateMachineWorkflowInstance to read the current state of the workflow it locked the instance.
So here we are in WF4 and many people couldn’t move apps forward from WF3.5 because of missing functionality. You know I hate that so I set out to solve this problem as quickly as possible which means fixing it with Microsoft.Activities.Extensions.
Unlike WF3, in WF4, any activity can contain a state machine, including other state machines. Therefore any workflow may have multiple state machines, each of which could be in a different state, however only one of them is active at any given time.
The solution is to use a tracking participant and persistence participant to track the current state and possible transitions. There are two classes which you will use to do this.
I’ve written a couple of samples that will show you how to do this with WorkflowApplication and Workflow Services