How can I improve the edit-compile-test loop when developing a SharePoint workflow?

Question

Recently I had to develop a SharePoint workflow, and I found the experience quite honestly the most painful programming task I've ever had to tackle. One big problem I had was the problems I encountered when I had to step through it in the debugger.

There's an article on how to debug a SharePoint workflow here that tells you how to set breakpoints etc. This involves copying the .pdb file into the GAC alongside the .dll file containing your workflow. You have to do this from a command prompt (or a batch file) because Windows Explorer doesn't let you view the relevant subdirectory of c:\windows\assembly.

However, if you do this, the next time you try to deploy the workflow from within Visual Studio, it complains that it can't be deployed because "the file may not be signed" and if you attempt to copy the new version of the dll into the GAC, it tells you that the .dll file is locked.

I've found that some of the time, you can get round this by doing an iisreset, but on other occasions you have to restart Visual Studio and there have been frequent times when I've even had to reboot the computer altogether because some mystery process has locked the file. When I don't use the debugger, on the other hand, everything works just fine.

Does anyone know of a simpler way of debugging workflows than this?

Answer 1

That sounds awful. I would also like to know if there is a better way to do this because our shop will start using SharePoint soon.

Answer 2

The SharePoint team is currently working on MOSS extensions for VS 2008 which will allow this type of functionality. This was available in VS 2005 with MOSS extensions, but has to be run off Windows Server with a full MOSS installation and the correct permissions set.

Answer 3

One thing that would really help is if the SharePoint team provided interfaces for the SP-specific workflow services needed to run SP workflows. This would allow you to mock those interfaces and run the workflows outside of SP proper. AFAIK, you can't do that today.

I've personally found SharePoint extremely painful to develop against... not just with workflows, but overall. I understand the administrative wins and the end user productivity, but it's a fairly dreadful experience for Joe .NET Developer.

Answer 4

As for speeding up the IIS reset, Andrew Connell has some tips here as well http://www.andrewconnell.com/blog/archive/2006/08/21/3882.aspx

This brought my IIS reset time from 10+ seconds down to less than 2 seconds.

Answer 5

I'm not sure you need to get the pdb file into the GAC. (At least, the fix I'm about to describe works just fine for debugging SharePoint web parts in VS2005, which have a similar problem.)

There's a checkbox marked "Enable Just My Code (Managed Only)" in Tools-->Options-->Debugging; if you uncheck it, then Visual Studio will happily load your pdb's from the bin\Debug folder where it built them. Probably. Can't hurt to try, anyhow...

Answer 6

I've got a lot faster developing SharePoint-Solutions in general (not only Workflows) when i started using WSPBuilder. WSPBuilder has a Visual Studio Addin called WSPBuilder Extensions and in my opinion the WSPBuilder Extensions do a better job than the infamous Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2. Thanks to the WSPBuilder Menu deploy/upgrade/uninstall of a solution is just one click away!

Answer 7

Check out STSDev on CodePlex by SharePoint MVPs like Ted Pattison, Andrew Connell, Scot Hillier, and more.

STSDEV is a proof-of-concept utility application which demonstrates how to generate Visual Studio project files and solution files to facilitate the development and deployment of templates and components for the SharePoint 2007 platform including Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). Note that the current version of the stsdev utility only supports creating projects with the C# programming language.

Keith