This blog has moved to http://blogs.msdn.com/b/appfabric please update your links!
The topic of 4.0 migrations has come up several times over the past week – in e-mail conversations with a few authors and meetings with customers, on a couple articles (e.g., Kathleen Dollard; Aaron Skonnard), and a cross-blog conversation. As such, it seemed a good time to post a couple blog entries on the topic. There will be more specifics coming out on this topic in the near term, but I’ll touch on that at the end of this entry.
As any of the links above will tell you, we announced at PDC that Windows Workflow Foundation (WF) will introduce a new WF workflow model in the upcoming 4.0 release of the .NET Framework, while continuing to carry forward and support the WF 3.0 model. Initially, this was met with great surprise by many folks – on blog entries, on Twitter, and on many a Facebook status update. In the PDC lounge and in the halls at PDC, we had the opportunity to discuss this topic at length – and the direction was also met with understanding and excitement after developers heard why we did it, and what this meant for them going forward.
In this blog entry, I would like to pull from some of those PDC conversations and highlight a few of the reasons why we made this decision to implement a new WF model, and what this means for you as a WF developer. My assumption is that you are familiar with WF 3.x today, and are wondering what this new version means to you. My next entry (probably next week) will highlight the scenarios that open up with WF 4.0 – what becomes possible with WF that had been very difficult in the prior release. I then intend to dive into some of these topics a bit deeper, hopefully drawing out a couple WF program managers to weigh in.
First, some quick context to set the stage - WF was first released as part of the .NET Framework 3.0. It was released as a set of next-generation .NET namespaces (along with Windows Communication Foundation (WCF) and Windows Presentation Foundation (WPF)) that enabled Windows Vista, Office 2007, and a range of customer solutions to do some amazing things. WF capabilities were extended in 3.5 to enable a more natural integration with WCF and to allow workflows to be service-oriented in a much more natural fashion. The goal of 3.0 was to create a single foundational technology that Microsoft products could build upon, and to ship this technology in the .NET Framework so that ISVs and customers could build upon it as well. This would provide customers with a unifying technology that would allow them to encapsulate and express business logic. And, in this, I think WF 3.0 was tremendously successful – today customers can build activities, and host them in custom WF workflow code, or in SharePoint or Dynamics or Office Communications Server or a variety of third-party ISV applications. And this next year will see even more products betting on the WF platform.
As we were designing WF 4.0, we wanted to address the feedback and pain points that we have gathered over the past few years from the community (via the Connect site, the forum, and discussions at with you at our events and deep dives) and implemented the following improvements:
As we expanded WF, it became clear that the WF 3.x architecture just wasn’t created with the above in mind. And while we could incrementally build on top of the existing platform, it would provide a less than optimal experience for developers, and might feel more like death by a thousand cuts. And, given a strong view by the average developer that the technology was already overly complicated, we made the hard choice to rewrite the WF framework and take advantage of what the other WinFX technologies provided.
So that gives you an idea of why we went and ripped up the garden, so to speak. You’re now asking – so do I have to rewrite my applications? The answer is it depends on whether you’re content with what you have now, or if you want to take advantage of the new WF 4.0 capabilities.
If you’re happy with your WF 3.0 workflows today, you do NOT have to rewrite your WF code, they will absolutely continue to work – even if you want to use Visual Studio 2010 and other features of .NET 4.0. We are shipping the 3.x designers and namespaces with .NET 4.0; you can continue to support and develop 3.5 workflows in Visual Studio 2010.
If you want to take advantage of the WF 4.0 capabilities, you can start to move your activities and workflows over as you feel comfortable. We’re including WF 3.x -> WF 4.0 interop capabilities (via a WF Interop activity) with .NET 4.0, which allow your 4.0 workflows to call back to 3.5 workflows and activities. In anticipation of your follow-up question, the Interop activity can only embed 3.x activities in 4.0 workflows; you cannot embed 4.0 activities in 3.x workflows.
So, all of that being said, 3.x WF developers have three options with .NET 4.0:
To help you with getting your head around this, we are putting a large effort around developing resources for migrating mindsets, skill-sets, and code/markup – authored by those close to the code, MVPs, and early-adopting customers that have been working with WF 4.0 and actually working with their WF 3.x code. This information will start being released along with Beta 1 and continue through and beyond RTM of .NET 4.0. Additionally, folks in the community are writing articles on the topic; for example, Kathleen Dollard did a short write-up on writing WF code today with 4.0 in mind in this month’s Visual Studio Magazine; we can’t highlight her #1 suggestion enough – use custom activities instead of using Code activities (and the code-beside they lead to) in your workflows today.
Perhaps the best assurance I can give you here is that we’ve been working with customers in our early-adopter Technology Adoption Program (TAP) and a variety of externals around our 3.x -> 4.0 options and process. And, while I can’t promise it will be painless, I’m hoping you will be pleasantly surprised with our Beta 1 release.
And, for those who adopted WF as part of the .NET Frameworks 3.0 and 3.5; I want to give you a heart-felt thank you! We are taking great pains to ensure that your current investments in WF (both time and code) will continue to add value in 4.0 and beyond. Even within Microsoft, there are at a few large products (internal customers) will launch over the next couple years on WF 3.5 today as they evaluate and work to adopt 4.0 in a future release – so you better believe that the namespace and designer will continue to be supported and serviced.
We really hope that you’ll take a look at WF 4.0 for yourself and see that we have heard your pains loud and clear; as mentioned above, most of the improvements made can be directly mapped back to customer feedback. I’ve been on a couple teams here at Microsoft, and I am personally amazed at how the CFX team handles the customer feedback they receive – going directly into the team’s bug/enhancement tracking system to be grouped and worked. While this may not be the exact way that you envisioned WF evolving, please withhold your ire until you kick the tires with the betas and/or final release.
Note: Thanks to the Kenny Wolf and Bob Schmidt for their invaluable feedback and help on this entry.
Agile/ALT.NET Scott Ambler on Criteria for a Disciplined Agile Team Scott Bellware - Good Design is Easily Learned Mike Cohn on Establishing a Common Baseline for Story Points Hanselminutes Podcast 146 - Test Driven Development is Design - The Last Word
Interesting post, we're waiting more news about the future WF platform.
Any news about designer rehosting? We've a big customer need: having the possibility to author the WF design in a simple and intuitive manner. Actually, we have applications that makes use of WF for some business process. The WF are modeled in a certain way and customers asks to have a tool (or something similar) for editing the WF structure in order to suite their business needs.
Are there plans about this?
Have you taken a look at Matt Winkler's PDC session? If not, I would definitely recommend checking it out (http://channel9.msdn.com/pdc2008/TL21/), and tune into the 63 minute mark.
The short answer is that the WF team has made it much easier to rehost the designer. Using XAML for WF 4.0 has made it possible to rehost the designer on a WPF form using about three lines of code. This makes is possible to construct your custom designer in Expression; which looks pretty snazzy compared to the rehosted designers of 3.x.
Hope this helps,
Thank you for submitting this cool story - Trackback from DotNetShoutout
こんにちは。 Tech Days へのご参加、ありがとうございました。 私が担当した WF/WCF/ワークフローサービス 4.0 のセッションについて、セッション後、互換性や移行に関して参加者の方よりご質問を頂きましたので、補足させていただきます。
Just some links that I caught up with today that struck me as interesting. Ribbon UI in Silverlight Tim’s
By now you must be aware of the significantly enhanced Windows Workflow Foundation (WF) scheduled to