I was working on a short workflow project for a client a couple weeks ago that was targeting WSS. Just a simple workflow to provide some enhanced blog posting features -  nothing crazy. I typically spin up a new virtual machine for each project from my base developer virtual machine so I have a clean slate but I was being lazy and this was a quick module so I decided to just ride on the virtual machine that I already had spun up for another project. However this virtual machine had MOSS installed but I was already aware of some of the caveats with developing workflows targeting WSS.

I don’t use Microsoft’s SharePoint\Workflow project templates because they don’t support 32bit (boooo!) so I’m not sure if this is an issue with that project type but there are a couple things to consider especially if you're using wspbuilder’s workflow template like me. This is fairly common knowledge with a few searches so I won’t get into great detail but you will need to make some adjustments to the out of the box workflow project template to allow it to successfully deploy\run in a WSS environment as it contains some MOSS dependencies by default:

1) Remove any reference to moss\office assemblies in the project:

2) In your generated elements file remove the references to the forms (AssociationUrl, InstantiationUrl,ModificationUrl, StatusUrl). These are references to pages only available in MOSS.

You may be asking why these pages become an issue. In short these are Infopath Forms Server forms. Unfortunately WSS does not have access to forms server so these are unavailable.

On a side note I was chatting with my co-worker Michael Lotter the other day who did confirm from a MS resource that you can use InfoPath Forms Server forms in workflows for MOSS Standard but only within the context of workflow forms, anything beyond that and you’ll need MOSS enterprise.

3) Remove the default TaskListContentTypeId (unless you are implementing a custom one).

Without these steps you’ll run into problems installing the workflow. Now in my haste I neglected to remove the TaskListContentTypeId. Unfortunately for me the workflow feature successfully activated, I was able to add a workflow reference to my targeted list, but from there things got strange. It would have been easier if I just got an ugly incomprehensible error but SharePoint wanted to keep me on my toes this day.

So if you’re like me and you forget to remove the TaskListConetntTypeId you may be left scratching your head for a while with the strange behavior. The workflow feature will install, activate, and you can associate the workflow with a list but you’ll notice right away that executing the workflow does nothing,the workflow status column shows no status, and no workflow history exists. You will not receive any exceptions, no event or ULS logs, things will simply not work. As with any development error the worst kinds are the ones that don’t throw any exceptions.

So moral of the story, if you’re targeting WSS and developing in MOSS make sure catch all your moss dependencies that may be injected in by your project template of choice or you may get a few surprises when you deploy to your staging\production environment.