As mentioned in earlier posts, I was one of the developers on the SharePoint Workflow feature in VS 2008. (shipped as one of the VSTO components - available in Professional SKU upwards)

The feature include a set of VS project templates, wizard, and VS project package that integrates creating, deploying, and debugging of SharePoint workflows into a streamlined, simplified experience.

Those who have used WSS SDK or MOSS SDK would realize that creating and debugging workflows in SharePoint is not an easy task. The main pillars of this feature were to significantly lower the learning curve for SharePoint workflow development, and make developers more productive. To achieve this, we knew that we had to optimize - what I like to call the code-build-debug cycle. That's where you are bound to spend most of your time while developing workflows, and any improvements there would be of great value.

Before VS 2008, typical code-build-debug cycle would be:

  1. Write the code
  2. Build the workflow project.
  3. Copy the latest feature.xml and workflow.xml files to the FEATURE directory.
  4. Remove any existing copies of the workflow assembly from the GAC.
  5. Add the latest version of the workflow assembly to the GAC.
  6. Re-start IIS.
  7. Install the feature with SharePoint using stsadm.
  8. Activate the feature at a SharePoint site where you intend to perform the debugging.
  9. Launch the web browser and go to the list that you want to associate the workflow with.
  10. Associate the workflow with  the list.
  11. Attach the debugger to the correct IIS worker process. (W3WP)
  12. Manually start the workflow.
  13. Debug the workflow.

The steps in red are scriptable, and WSS and MOSS SDK include batch files to enable that. However, batch files are difficult to maintain (source control, hard coding etc.?), error-prone (when something fails - what do you do?), and slow (more on this in another post). Rest of the steps are manual, tedious, and time consuming.

Using VSTO SharePoint workflow project templates, your code-build-debug cycle will be so simple:

  1. Write the code.
  2. Press F5 (builds, deploys files, associates the workflow feature in SharePoint, attaches the debugger to the correct W3WP process, launches the browser).
  3. Manually start the workflow.
  4. Debug the workflow.

Imagine this being repeated every time you make a change to your workflow. This is how VS 2008 already gives you a great productivity edge - you just need to now focus on designing your solution.

Get your copy of VS 2008 and give the feature a try, and drop me a line about how you find the feature.