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.
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.
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.
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.
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
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
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.
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.
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!
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
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.
Regarding “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.” Check out the Dell Precision M4400 with 8GB memory and Windows 2008 R2. I’m running that right now.
Best,
Greg
How is it that windows is able to incorporate the latest releases of .NET but SharePoint is not. It always seems that the SharePoint team is off doing something on their own.
From what I’ve heard unofficially from various low-level people at Microsoft, the SharePoint team could not bank on .Net 4.0 (which includes WF 4.0) being ready on time for the planned release of SharePoint 2010, so they went with .Net 3.5 SP1 instead. Again, this is unofficial from only a small number of people at Microsoft, none of whom is directly involved in the official SharePoint team at Microsoft. This means that all the .Net 4.0 “goodness” will have to wait for the next release of SharePoint. Throw in the fact that companies and (especially) governments are slow to upgrade their IT infrastructure and you’re talking at least four years before WF 4.0 becomes usable in a practical sense.
Sharepoint 2010 can also run on forinstance a Windows 7 Professional laptop for development mode. No need for a server. Check http://msdn.microsoft.com/en-us/library/ee554869.aspx
Sharepoint 2010 will support .NET 4.0, Microsoft is working on this, however it is not yet available
Sharepoint 2010 however already can work with WF 4.0, WF 4.0 is build on .NET 4.0 but you can run WF 4.0 by calling a WCF host (external site from Sharepoint).
Until I see SharePoint 2010 Enterprise workflows designed, deployed and run from Visual Studio 2010 using direct WF 4.0 activities, I stand by my earlier comments. If Microsoft wants to slipstream full WF 4.0 support into SharePoint 2010, that will be great, but something tells me not to hold my breath waiting for that to happen.
As for Windows 7 as a viable SharePoint 2010 development environment, I have two words that shoot that idea down: Active Directory. Only in a virtual machine environment running AD on a Server Operating System can I have the type of sandboxed (from an AD perspective) environment where I have my own private AD to use for testing and experimenting without affecting anyone else. If anybody knows how to do the same thing with Windows 7, I stand ready to be corrected, but somehow I doubt that’s going to happen.
I’ve read over the improvements to 2010 workflows, and they still do not address the main horrendus shortfalls of sharepoint 2007 workflows.
- Inability to resume after a sharepoint restore, or data migration.
- If a workflow fails, you are unable to restart it at the last workflow step.
I don’t know why anyone would use them for a complex business process, there just not up to scratch.
My understanding is that WF 4.0 was not “fully baked and ready to go” when SharePoint 2010 was being designed and coded; therefore, we’re stuck with WF 3.0 in SharePoint 2010 workflows designed using the SharePoint 2010 workflow templates included in Visual Studio 2010.
One of three things will probably happen:
1. The ability to create and run WF 4.0-based workflows in SharePoint 2010 with full “tooling support” (replacements for the SharePoint 2010 workflow templates in Visual Studio 2010) will be slipstreamed in via a Service Pack (probably not SharePoint 2010 SP1).
2. Somebody will come up with a crude, “feels like it’s bolted not, not built in” kludge to make it possible to create and debug SharePoint 2010 workflows based on WF 4.0. Keep your eyes on CodePlex and other open-source locations because waiting on Microsoft to act requires near-infinite patience.
3. We wait until the next version of SharePoint (2014?) and hope it at least supports WF 4.0 via the “tooling” (Visual Studio). Don’t hold your breath expecting the next version of SharePoint to fully support the next version of WF (4.5? 5.0?).