Initial Thoughts On SharePoint 2010 Workflow Development Using WF 4.0, Visual Studio 2010
Posted by fredmorrison on 2009-01-21
After reviewing the workflow-related videos from PDC 2008 and the SharePoint-related videos about Visual Studio 2010 on Channel9, I’ve come to the initial conclusion that SharePoint 2007 was not the “real” SharePoint for developing real-world workflows. By that I mean that SharePoint 2007 is merely a “revenue making place holder” for Microsoft until the real SharePoint (2010, a.k.a. 14) comes out, complete with “proper tooling” for creating real-world workflows.
Think about how many add-ons it takes to turn Visual Studio 2005 into a viable custom SharePoint workflow creator. Visual Studio 2008 takes fewer add-ons, has improved debugger support and some deployment capabilities, but still lacks built-in capabilities to perform fundamental “duties” like generating a WSP. You still need add-on tools from CodePlex and other places to turn Visual Studio 2008 into a half decent custom workflow development tool.
Even the latest CTP for Visual Studio 2008 Extensions for WSS version 1.3 does not provide the new Package or Retract commands for any project based upon the Office 2007 SharePoint Sequential Workflow template. I know. I tried it and found out the hard way that the workflow project templates in Visual Studio 2008 SP1 are still second-class citizens when it comes to VSeWSS. You still need WSPBuilder and other tools available from third parties to perform the things that Microsoft tools still won’t do.
Don’t you just love the “flying blind” approach to creating ASP.Net workflow task forms in Visual Studio 2005/2008? May God have mercy on Microsoft if that is still the case in VS 2010. Better yet, why not let me design MOSS 2010 workflow task forms using WPF, perhaps in combination with Expression Blend or a similar XAML-based GUI design tool?
It’s only in Visual Studio 2010, together with .Net 4.0, WF 4.0 and its underlying XAML do we see (at least from the videos I’ve watched and the MSDN Developer Conference I recently attended) what I call “professional grade” tools for developing complex custom SharePoint workflows. You can read about some of the improvements in the January 2009 edition of MSDN Magazine.
The fact that the workflow engine and the Visual Studio 2010 workflow designer were completely rewritten should tell you a lot about how Microsoft regards the quality of the “developer experience” when designing, coding, and even unit testing a custom SharePoint 2007 workflow in Visual Studio 2005/2008. I found myself spending more time “wrestling” with SharePoint, InfoPath 2007 and WF 3.x to overcome their short-comings rather than spending time on the business process that caused us to turn to custom SharePoint workflows in the first place. Have you ever sprinkled extra Delay Activities as part of a loop in your custom workflows for the sole purpose of waiting for the workflow to serialize a workflow task and thus generate the needed ID value for the purposes of generating a hyperlink value? With SharePoint 2010 workflows, all you have to do is issue a Persist command. Where was this KISS principle two years ago? Probable answer: not enough time and too much pressure to keep feeding the Microsoft “revenue machine”, which requires regular feeding a minimum of four times a year when those all important 10Q and 10K reports are reviewed on Wall Street.
As more and more information about the initial “tooling” for SharePoint 2010 workflow development becomes available, perhaps in the form of downloadable virtual machine images, I’ll be interested to see if other people come to the same conclusion about the viability of the “tooling” that was initially delivered by Microsoft for SharePoint 2007 workflow development (i.e., minus all the subsequent add-ons).
The short version of this article: Under VS 2005/2008, SharePoint 2007 workflow development was more of a “bolted on” (after the fact) experience, not the “built in” experience we were all looking for.
Now if I could only find a decent 64-bit laptop running Windows Server 2008 R2 (a.k.a. Windows 7 Server) for that next SharePoint development machine…oh, well, subject for another post.
will333 said
Fred
Couple of things on office 14’s workflow you mentioned above:
- Office 14 (or sharepoint 2010 to use your words) wont be supporting .NET4 and WF 4.
- Office 14 still uses workflow foundation 3.5 and .net 3.5 and you wont get the same benefits compared to when you use only .net 4 solutions in custom development.
- The workflow platform for WF 4 was indeed rewritten from the ground up and is a much better platform, however, we will have to wait for office 2013 (or office 15) before we can use this for sharepoint development.
- WF4 does provide some out of the box sharepoint activities, but these are very different from SharePoint’s workflow and is build by the WF team, rather than the Office 2010 team.
So we will end up with 2 workflow platform versions with the latest one being rewritten from the ground up and the 2nd one being the core of SharePoint’s workflow engine, but still exactly the same WF3.5 workflow in the current SharePoint :-(
You will still use the current WF 3.5 workflow designer for SharePoint 2010 (Office 14) workflows in Visual Studio 10.
With that being said the workflow design in SharePoint Designer for Office 14 is much improved and so is the Visual Studio 10 templates for developing WF 3.5 based MOSS workflows.
It still is a heavy heavy developers experience, but you can clearly see Microsoft making the necessary improvements and investments.
fredmorrison said
Thanks for the insider insights. It looks like SharePoint workflows, at least the kind I write for MOSS 2007 in Visual Studio, won’t be improved until Office 15 SharePoint Server (or whatever name they call it) and the version of Visual Studio that comes after 2010. Given that situation, I can’t wait for SharePoint 2010 to come out, just so Microsoft can move on to the next edition, which is the one I need.
JesseMurray said
Why must we wait for next versions in multiple year increments? Microsoft needs to release .Net 4.0 support as a SharePoint 2010 SP1.
Fred, I can’t agree with you more on the tooling aspect of SharePoint and workflow. This question sums it up for me: “Why is it so difficult to do SharePoint workflow?”. I’d like a viable answer. I may shed a tear if I have to wait for the “flow” workflow type in .Net 4.0 until SharePoint vNextNext.
decatec said
I believe MS is really missing out on all the BMP/SOA action by having such poor WF tools. MS needs a tool to allow creating WFs easily spanning from Outlook, Sharepoint, CRM, Biztalk, Exchange and even SSIS
Joseph Davoli said
Dear Fred,
I just went through considerable effort to set up a MOSS 2007 development server, 32-bit, which sits in another part of the building. I also got a brand-new desktop in my cube and installed and updated Visual Studio 2008. As I began my first SharePoint 2007 Sequential Workflow project, I received the following error:
A 32-bit version of SharePoint Server is not installed. Please install a 32-bit version of SharePoint Server.
The results of a quick Google search suggest that VS2008 and MOSS2007 must be sitting on the same machine (or in the same virtual machine) in order for me to develop workflows with VS2008. Is that the case?
I appreciate any insights you might share.
Sincerely,
Joseph Davoli
fredmorrison said
You have to have Visual Studio and SharePoint on the same real or virtual machine running either Windows Server 2003 or Windows Server 2008. Worse, that’s probably not going to change for the better with MOSS 2010, which will be 64-bit only, unless Microsoft takes the Exchange Server 2007 SP1 route and allows MOSS 2010 to be installed for evaluation/development purposes only on a 32-bit Server OS.
Craig Porter said
I naively dived into sharepoint workflows the minute that MOSS 2007 was released. Unfortunately the initial sharepoint workflow platform was riddled with bugs that proved not only irritating but down right frustrating. That pesky delay activity was the bain of my life!! Only after a number of patches did WF in sharepoint actually stabilise. There was little documentation on how to use some of the built in activities properly (replicator anyone??) Hopefully this time round the product will be more mature more stable and with heaps more support for the developer.
=8)-DX said
Precisely: I was made to work on both the at the time completely undocumented early SharePoint versions (the betas), and following that I was made to work on SharePoint workflow – both are still buggy as of today (even worse when you put the two together.)
“heaps more support for the developer.”
To me it has always seemed like SharePoint workflows were programmed as an internal tool for the MS SharePoint team to make some “shiny” nice approval workflows, and a plethora of “Hello World” Visual Studio workflow designer presentations.
All my experience with SharePoint has been: Try it the most obvious way in the object model (SPListItem.MoveTo), when that doesn’t work, try changing the parameters of the methods, run with elevated privileges etc etc. Fish around for alternate solutions in the OM. Solution: a complete dumb workaround (recreate the item from scratch, iterating through versions and copying all attachments one by one then delete the original – oh and also set up roles and users.).
And workflows the same: “Oh cool you can put State Machine Workflow StateActivites inside each other! That’s just what my workflow needs! Now I’ll put an OnWorkflowItemChanged on the outer one. Yey! Oh. It doesn’t work. Back to the drawing board.”
And now I’m working on a two-workflow 38-state business process implemented as SharePoint Workflow.. HELP!
Rodrigo said
Fred,
Here in our company we do, as you said, “real world” workflows. We have very complex workflows and infopath forms and now we are facing a problem (OnTaskChanged not firing, what a new, ahm?) and I have an open case in Microsoft and they insist saying that I´m using the OnWorkflowItemChanged in a wrong way.. but the fact is that´s no documentation about the restrition and we have anoter environment where the same workflow is working fine.
There is an exception (EventDeliveryException) raising in my ULS logs and they are simply ignoring this.
The Microsoft WWF infra-structure must improve a lot to be bad.
Regards,
Rodrigo de Castro Reis
rodrigo.reis@invit.com.br
decatec said
Sharepoint Workflows depend on Service Packs AND versions of .NET and SQL Server, we’ve learned it the hard way. Now we work always on the same versions the clients have.