Partager via

Workflow Foundation: Migration from WF3 to WF4 - Notes and References

  • Article

As you probably know, the .NET Framework 4.0 is going to introduce a new object model for the Workflow Foundation (WF) technology, in short called WF4, which will be added to the existing WF object model, in short called WF3. The WF3 object model uses the namespaces System.Workflow.*, whereas the WF4 object model uses the namespaces System.Activities.*.

Our product group published a Migration Guidance set of documents, available for download at https://go.microsoft.com/fwlink/?LinkID=153313.

 

I strongly encourage everyone working with WF to read those documents and to check the team blog at https://blogs.msdn.com/endpoint. In the following I report some quick takeaways, mainly coming from those documents and from questions we get from customers. Note that these notes are by no means meant to be a replacement to reading the whole set of documents.

  • .NET Framework and Development Environment: a very important aspect, not always well-understood, is the fact that WF3 is in .NET Framework 4.0. In other words, it is possible to run worflows using the WF3 object model on top of the CLR 4.0 and the .NET Framework 4.0 Class Library. The WF3 Designer runs in Visual Studio 10, so everything that could be done with WF3 under the CLR 2.0 and the .NET Framework 3.x can also be done with WF3 under the CLR 4.0. A consequence is that it is not necessary to use Visual Studio 9 in order to author/build/debug WF3 applications: Visual Studio 10 will works with WF3 
  • Rules: forward-chaining of rules is missing in WF4 (at least in its initial version). If forward-chaining is needed, you may consider using WF3 even for new development. This could be conveniently wrapped in a custom WF4 activity. The Policy40 SDK sample exemplifies this concept
  • State Machine Workflows: in my support activity on WF I have seen several customers using this type of workflow. There is no direct equivalent in WF4, but the new Flowchart activity can conveniently model some of the state machine workflows: typically, those where the flow is mostly sequential and "non-sequential" links betwen states are more the exception than the rule. For State Machine workflows that are not easily modeled with a Flowchart activity, staying with the WF3 object model is a valid option
  • Workflow Services: the term "Workflow Services" designates workflows that communicate with the outer world through WCF. In other words, they are the business logic of a WCF service. In WF3, workflow services used the ReceiveActivity activity in order to receive incoming WCF calls. In WF4 ReceiveActivity plays a different role, that of receiving a SOAP request. Therefore, a WF3 ReceiveActivity activity with the "One Way Operation" unchecked (request-reply MEP) is typically replaced, in WF4, by a pair of activities: Receive and SendReply. The WF4 object model is more flexible in modeling MEPs other than Request-Reply

Comments

  • Anonymous
    October 29, 2013
    Update: as of Update 4.0.1 (KB2478063), and in any new version starting from 4.5, the .Net Framework includes activities for creating State Machine Workflows. msdn.microsoft.com/.../gg983472(v=vs.100).aspx is a good starting point if you want to create your first state machine workflow in WF4. Enjoy!