Are there design patterns for writing SharePoint workflows that will be upgradable?

Question

Howdy,

I have asked a question on another thread about upgrading long running workflows and have not received an answer that I wanted to hear. (http://stackoverflow.com/questions/357032/how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production)

The answer, which matches up with the other research I have done on this topic, suggests installing the new WF (workflow) in a side by side method and marking the old WF as no new instances.

I have read that if the new WF has the same interface then there may be a possibility just replacing the original WF's dll and the existing long running workflows will continue to function.

Is there a design pattern, or guidelines, that would be useful in creating the original workflow allowing for code changes over the life-cycle of a product, without having to replace the workflow in each SharePoint List instance?

Answer 1

There are two parts to a workflow in SharePoint - .net code and xml configuration.

For changes in the code, you can make changes and redeploy your solution package - as long as the strong name of the assembly doesn't change the new code will get called the next time an event occurs on an existing workflow. You just need to be careful when making changes that your code doesn't assume that the workflow was started using the current code.

Any changes in the xml configuration (effectively the interface definition for the workflow) will require the more complete new deployment.