Category: keep previous version of state machine workflow

Versioning of Visual Studio SharePoint Workflow

This article is copy of
Phil Wicklund’sbook of SharePoint Workflow

Thanks to him for solving biggest problem of Sharepoint State Machine Workflow.

You built this compelling Visual Studio workflow and deployed it into production.
But, after a few months, the business requests a small change to the workflow. You go
back into the workflow code, add a few activities to fulfill the request, and redeploy
the workflow into production. To your shock, all the workflows start breaking! You’re
frantic because you’re certain you adequately unit-tested the changes and can’t figure
out what might be going wrong. You didn’t version your workflow.
Workflow versioning is an important technique. When a workflow goes idle, the
state of the workflow is saved into the database. This saving of a workflow’s state is
called hydration. When the workflow resumes, the state is dehydrated out of the database,
and the workflow starts processing again. Versioning is important because, if you
change the assembly while the workflow is hydrated (saved in the database), there’s
no guarantee that, when the workflow is dehydrated, it will match the construct of the
new assembly. If it doesn’t match the construct upon deserialization, the workflow will
break. Changes like adding or removing activities and changing property values may
necessitate a new workflow version. The best practice is to create a new version every
time rather than deploying the assembly and crossing your fingers.
Think of a new workflow version as a new workflow. The basic technique is to
make your assembly increment the version number with each build (rather than leaving
it at 1.0.0.0 forever). Then, for each upgrade, you create a new feature for that
version of the workflow, pointing to the new assembly. You add the new assembly into
the global assembly cache (GAC) alongside the old assembly. Last, you specify that
the old version cannot start new instances of the workflow and then you add the new
workflow onto the list. This way, the old version of the assembly never changes, so
there’s no risk of hydrated workflows breaking when they are dehydrated. You deploy
another version of the assembly and add the new workflow to the list and disable previous
versions. You don’t want to remove the previous versions because that will
orphan those running instances. For the full set of procedures, follow the steps in
table below to create a new version for an existing workflow.

Old version overwritten
If you don’t create a new version and merely upgrade the solution, all running instances
of the workflow will be deleted. The old version of the workflow will be removed,
and the new version will be added with zero running instances. Don’t
upgrade without creating a new version unless you’re entirely sure you don’t need
to retain the running instances.

Action
Steps
Result
Create version
1.0.0.0 in your
workflow’s elements
file.
1 In the Elements.xml file of your workflow, replace $assemblyname$
in CodeBesideAssembly with the following:
[assembly name], Version=1.0.0.0,
Culture=neutral, PublicKeyToken=[token]
2 Replace [assembly name] with your assembly name.
3 Replace [token] with your public key token. You can do this by finding
your assembly in the GAC (c:\windows\assembly) and rightclicking
it, choosing Properties, and copying the token.
4 Change the name of the workflow in the Elements file to reference
the new version.
NOTE: This ensures that the user working with the workflow knows
what version it is. It has no technical implications. For example
 
5 Add a copy of version 1.0.0.0 to solution package by double-clicking
on the Package and, under the Advanced tab, add an existing
assembly and browse to your 1.0.0.0 assembly version:
NOTE: Notice how the Location and Source of the assembly are in a
path under Version 1.0.0.0. When the package is created, the
1.0.0.0 version is put in its own path. It cannot be in the same path
as the current version because they both have the same name.
Your workflow’s feature
is now specifically referencing
the 1.0.0.0 version
of your assembly
With version
1.0.0.0 established,
you can
now simulate the
need to create
version 2.0.0.0.
Change the version
of the
assembly
to 2.0.0.0.
1 Under the Properties folder in the solution, open the Assembly-
Info.cs file.
2 Scroll to the bottom of the file and change the two versions to
2.0.0.0.
The current version of
the workflow’s assembly
is now 2.0.0.0.
Update the workflow’s
Elements.
xml file to
reference both
the version
1.0.0.0 workflow
and now the new
2.0.0.0 version.
1 Under the workflow, open the Elements.xml file.
2 Copy the Workflow element in its entirety and paste it directly
after the tag.
3 Change the name and the version (in the CodeBesideAssembly) of
the second workflow to reference version 2.0.0.0.
4 Change the ID in the 2.0.0.0 version to a new GUID. You can create
a new GUID by using the Create GUID tool under the tools menu.
5 Build and deploy the solution.
The workflow’s feature
now enables two workflows.
The main difference
is that one is
referencing the 1.0.0.0
assembly, and the
other is referencing the
2.0.0.0 assembly.