article is taken from the book SharePoint 2010
Workflows in Action. The author
discusses the best practice of creating a new version every time a change is
made to a workflow.
off any version of SharePoint 2010 Workflows in Action with the checkout code dnspark40. Offer is only valid through
Say that you've built this compelling Visual Studio workflow and deployed it
into production. 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 stop working correctly! 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
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 220.127.116.11 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 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,
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 1 to create
a new version for an existing workflow.Old version overwrittenIf 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.
Table 1 Creating a new version for
an existing workflow
Figure 1 By deploying a 18.104.22.168 version of the
workflow, all running instances of 22.214.171.124 will dehydrate without error when
they resume execution. Users can no longer start new instances of version
|Create version 126.96.36.199 in your workflow's elements file.
||1. In the Elements.xml file of your workflow, replace $assemblyname$
in CodeBesideAssembly with the following:
Version=188.8.131.52, Culture=neutral, PublicKeyToken=[token]
[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 right-clicking it, choosing Properties, and copying
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 which version it is. It has no technical implications. For
Add a copy of version 184.108.40.206 to solution package by double-clicking on the
Package and, under the Advanced tab, add an existing assembly, and browse to
your 220.127.116.11 assembly version:
Notice how the Location and Source of the assembly is in a path under Version
18.104.22.168. When the package is created, the 22.214.171.124 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 will now be specifically referencing the
126.96.36.199 version of your assembly.|
|With version 188.8.131.52 established, you can now simulate the need to
create version 184.108.40.206. Change the version of the assembly to 220.127.116.11.
||1. Under the Properties folder in the solution, open the
2. Scroll to the bottom of the file and change the two
versions to be 18.104.22.168.
|The current version of the workflow's assembly will now be
|Update the workflow's Elements.xml file to reference both the version
22.214.171.124 workflow and now the new 126.96.36.199 version.
||1. Under the workflow, open the Elements.xml file.
2. Copy the
Workflow element in its entirety and paste it directly after the
3. Change the name and the version (in the
CodeBesideAssembly) of the second workflow to reference version 188.8.131.52.
Change the ID in the 184.108.40.206 version to be a new GUID. You can create a new GUID
by using the Create GUID tool under the tools menu.
5. Build and deploy the
|The workflow's feature will now be enabling two workflows. The main
difference is that one is referencing the 220.127.116.11 assembly and the other is
referencing the 18.104.22.168 assembly.|
|Activate version 22.214.171.124.
||1. In the root site in the site collection, click Site Actions and
then click Site Settings.
2. Click Site Collection Features.
Deactivate and reactivate your workflow's feature.
|The 126.96.36.199 workflow is able to associate with lists or
|With version 188.8.131.52 deployed and activated, you now need to prevent
any new instances of version 184.108.40.206.
||1. Navigate to the workflow settings page of the List or Site you're
2. Click Remove a workflow.
3. Disable new instances in
version 220.127.116.11, and click OK (figure 1).
|The 18.104.22.168 version can no longer be started, but running instances
will dehydrate without error.|
Versioning workflows is sometimes new to
developers. When a workflow is persisted to disk (hydrated), subsequent changes
to the workflow's assembly can cause problems. If you change the assembly while
the workflow is hydrated (saved in the database), there's no guarantee that,
when the workflow dehydrated, it will match the construct of the new assembly.
If it doesn't, the workflow will break. Instead, a new version of the workflow
must be published.