Windows Workflow Foundation built-in persistence support can be extended by its host to save additional data. There are a couple gotchas to be aware fo when trying to ensure transactional consistency between the built-in and host-specific data.
One of the more attractive parts of Windows Workflow Foundation is its workflow designer and the possibility of rehosting it in your own application with a minimum amount of code. Often simple rehosting of the designer is enough, but sometimes you will want to do some additional background processing of the workflow as the user is designing it. In this article I'm going to present a way for achieving that.
Certain aspects of Workflow Foundation are still poorly documented; the persistence framework being one of them.
While refactoring an application hosting workflow foundation runtime, I stumbled upon an inconsistent behavior in handling and validation of workflow extensions added to the host WorkflowApplication.
On Monday our local Microsoft subsidiary organized Visual Studio 2012 bootcamp as a preconference to Bleeding Edge 2012. For my talk I selected 3 new features in .NET Framework 4.5 that excite me most.
On Wednesday I had a talk at NT konferenca 2012 about the changes in Windows Workflow Foundation that we can look forward to in .NET Framework 4.5. The slides from the talk are available in my OneDrive.
Windows Workflow Foundation (WF) is an often overlooked part of .NET framework but its declarative approach to defining workflow logic can prove useful in spite of the steep learning curve and some unfortunate limitations. Once you get to know it, you might even come up with new creative ways of using it.
When architecting solutions using Workflow Foundation it is typically necessary to provide information to individual activities. But apart from standard input arguments being passed to the workflow or originating from previously executed activities, which can best be modeled using InArgument<> properties, there is often also a need to access some kind of contextual information in the activity. In this post I'm going to discuss three different approaches to providing such context to a custom workflow activity.