Sharepoint Workflow Versioning
I debated whether to make the title of this post "What Happened To Versioning With SharePoint 2007 Workflows?" but decided that was too crude. The next title of this post was "Shout Out To Wiggins (party at ILTA -- the first one I'll miss in 9 years)" but decided that was too cryptic so I went with the a boring but subject matter title. The truth is, there really isn't traditional versioning with SharePoint Visual Studio workflows (SharePoint Designer workflows take care of versioning and deployment for you). You cannot simply create a new version, expect the old workflow to pick up the correct assembly and new workflows to pick up the new one. Instead, the "best practice" method for versioning workflows is really to create a new version and therefore a new workflow.
I've seen a lot of companies dealing with this issue. They deploy Version 1 and a month later have Version 2. What most of them tend to do is simply make a static version number, deploy the assembly to the GAC and cross their fingers. Unfortunately what ends up happening is a series of unfortunate and oftentimes cryptic error messages or, worse, non-error messages. Oftentimes it takes the form of an In Progress workflow, a task edit and the workflow never moves on... a user continually tries to update their task and instead is met, each time, with the message that the task is locked by a workflow. A vicious cycle.
So, in short, the unfortunate circumstance is that you have to deploy the new version as if it were a completely new workflow. It must be reassociated to the lists and libraries as if it were new. You have to set the previous version to "No New Instances" (which will actually automatically happen when you deploy a new version) and, most irritatingly, you get the secondary workflow status column in your default view. For the record, I did double check with my sources to determine if I was missing something but, as far as I'm aware, you really do have to reassociate new workflow instances and treat them, essentially, as a new workflow. This is a huge oversight on the part of the SharePoint workflow team and, hopefully, one that is rectified in future releases.
More bad news comes when we talk about forms versioning. There is no really clear picture with regard to forms versioning. For my purposes, I have made sure that fields previously versioned workflows needed remained in the form even when I didn't need them for future versions and updated the form.
I found this interesting blog entry by Dan who talks about the versioning issues with SharePoint workflows. An interesting solution but just a workaround to a larger issue and most organizations would be hesitant to create custom code to deal with a shortcoming of the product.
So, readers, what do you do to "support" workflow versioning with SharePoint? I have a few interested parties with their eyes open to hear about it!
-----
As a side note, I get a lot of emails asking me for specific support for specific error messages with SharePoint workflows. I am usually happy to try and help but please understand that I can't troubleshoot a black box. It is generally best to send me snippets of code, your workflow project, or pictures of error messages to work from. It is really hard to troubleshoot "My workflow won't start" emails.