.NET Tutorials, Forums, Interview Questions And Answers
Welcome :Guest
 
Sign In
Register
 
Win Surprise Gifts!!!
Congratulations!!!


Top 5 Contributors of the Month
david stephan

Home >> Articles >> SharePoint >> Post New Resource Bookmark and Share   

 Subscribe to Articles

Versioning workflows

Posted By:Manning       Posted Date: January 30, 2011    Points: 75    Category: SharePoint    URL: http://www.dotnetspark.com  

Versioning workflows in Sharepoint 2010. 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
 


This 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.


G
et 40% off any version of SharePoint 2010 Workflows in Action with the checkout code dnspark40. Offer is only valid through www.manning.com.


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 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 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 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.

Table 1 Creating a new version for an existing workflow

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 right-clicking 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 which 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 is 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 will now be 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 AssemblyInfo.cs file.
2. Scroll to the bottom of the file and change the two versions to be 2.0.0.0.
The current version of the workflow's assembly will now be 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 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 solution.
The workflow's feature will now be enabling 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.
Activate version 2.0.0.0. 1.  In the root site in the site collection, click Site Actions and then click Site Settings.
2.  Click Site Collection Features.
3.  Deactivate and reactivate your workflow's feature.
The 2.0.0.0 workflow is able to associate with lists or sites.
With version 2.0.0.0 deployed and activated, you now need to prevent any new instances of version 1.0.0.0. 1.  Navigate to the workflow settings page of the List or Site you're working on.
2.  Click Remove a workflow.
3.  Disable new instances in version 1.0.0.0, and click OK (figure 1).
The 1.0.0.0 version can no longer be started, but running instances will dehydrate without error.



Figure 1 By deploying a 2.0.0.0 version of the workflow, all running instances of 1.0.0.0 will dehydrate without error when they resume execution. Users can no longer start new instances of version 1.0.0.0.

Summary


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.


SharePoint 2010 Workflows in Action
EARLY ACCESS EDITION

Phil Wicklund
MEAP Release: May 2010
Softbound print: December 2010 (est.) | 400 pages
ISBN: 9781935182719


 Subscribe to Articles

     

Further Readings:

Responses

No response found. Be the first to respond this post

Post Comment

You must Sign In To post reply
Find More Articles on C#, ASP.Net, Vb.Net, SQL Server and more Here

Hall of Fame    Twitter   Terms of Service    Privacy Policy    Contact Us    Archives   Tell A Friend