Well, I said I’d blog about how well I managed with using SharePoint Workflows with ASPX forms. The short answer – badly.

First off, the SDK no longer seems to include the CollectFeedback workflow, which was the only example of building a workflow for WSS and, therefore, using ASPX pages. Great, thanks for removing my one example. I eventually dug out a copy (well, actually, a colleague did) – here it is for those of you who’re curious.

I also referred to the SharePoint Team Blog’s one post about ASPX forms for workflow, which made it all look pretty simple. Really, it isn’t simple. I read that post and it sounded pretty straight forward and sensible to me, but when I tried to do it, well, I was soon lost.

Next I referred to the book Workflow in the 2007 Microsoft Office System by David Mann. It has a whole section about using ASPX forms. Unfortunately, it doesn’t really describe how to create the code for one – it pretty much says ‘download what I’ve done’, which isn’t that useful. I still don’t know how he generated this code, or understand the principle behind what he’s done.

Reverse engineering it was a bit more more interesting – though still not exactly fruitful. It turns out that his example and the CollectFeedback example both

• Create a content type for each type of Task in the workflow, which could well mean a content type for each user Task in the workflow.
• Deploy their forms into the _layouts directory, so these forms are available farm-wide.

I’m not dreadfully convinced about either of these things.

I get the first point – although having a single task content type that supports multiple forms would be useful. Often, you have the same ‘body’ of data, but need different forms; this method means that for different forms, you have to write the population of data into them uniquely. However, it’s not very intuitive.

The second point is more irritating – that the Task forms have to go into the _layouts directory. Okay, at one level, that’s fair enough; adding new .aspx files is safe enough. But how will that fit with different versions of the form? You could have different versions of the workflow available in different web apps in your farm. Can I use the site’s own master page (rather than application.master)? I can’t see that being a problem, but it’s another thing to think about. What if we wanted customisation of some of these forms, as you can do for the forms on a library? The whole customising process thing is one of the neat (and mind bending) things about SharePoint – but we’ve not got that facility for our .aspx workflow forms.

Anyway, I tried writing my own workflow; it didn’t work. Or, more accurately, the workflow’s tasks using .aspx forms didn’t work. Repeated efforts continued to fail. Frustration mounted, and then I received an email from the Ted Pattison Group about the WSS3 Workflow tools. “Interesting”, I thought, “as they must use .aspx forms”.

Well, they do. I’ve not tried them yet, but hope to do so shortly (though I’m now out of prototyping time). Consequently, I can’t say if they’re any good, but to quote a commenter on my previous post:

Best case you find it useful, worst case, it’s an example of how to write custom ASP.NET WSS workflow forms.

It looks like a pretty good framework, anyway. This does also highlight one of the pain points about workflow development in SharePoint – there is a lack of basic tooling. Given how late the Workflow Foundation settled down and how soon after SharePoint was released, I can’t really blame the development team, but it does seem sad that the development story (usually so good in Visual Studio) was so basic.