This is the 3rd post about what is new with Windows Workflow Foundation in .NET 4.5 as announced at the //build/ conference. See also part 1 about the designer enhancements and part 2 about the other runtime enhancements.
This 3rd post is about one of the biggest missing pieces which is versioning workflows.
To understand why this is so painful at the moment it is important to remember that workflow instances often run for a long time. And that is not just a long time in computer terms, like a few minutes, but a long time in human terms like weeks, months or even years.
Right not with WF4 you can’t change the definition of a workflow instance that is running even when it is persisted to disk. Doing so will result in any number of weird exceptions when the workflow tries to resume. And the fact that you can’t change the definition means you can’t fix a bug, all you can do is let the workflow run and make sure that new instances are started with a fixed definition. Not the nicest of situations and I am very glad this is being addressed.
The first part is the ability to add a version to a workflow instance using a WorkflowIdentity object. This doesn’t fix the versioning issue itself but at least we get a predictable exception.
The second part if the capability to create update maps and update the state of a persisted workflow instance to a newer version. This capability gives us a lot of control as we can choose which workflow instance we upgrade and which we keep at the current version. Basically we create a DynamicUpdateMap and use the DynamicUpdateServices.PrepareForUpdate() to update a workflow instance state. A great and long awaited addition to the workflow runtime.
The final versioning piece is an addition to the WorkflowServiceHost allowing it to host multiple versions of a workflow. This is something we can now achieve using the WCF routing service but is far from trivial to implement. This should make the scenario of versioning workflow services much easier.