Versioning Techniques for Workflows



































As of right now, there are no documents (whitepapers) available that pertain specifically to workflow versioning other than what you will find on MSDN at http://msdn2.microsoft.com/En-US/library/aa349375.aspx.


 


However, out on the forum http://wf.netfx3.com, there have been several posts related to versioning and to give you an executive summary of what you need to do, there are basically two ways (without doing lots of coding) to handle versioning:


 



  1. Use workflows that execute based on XAML activitation.  This is where you just read in a .xoml file via an XMLTextReader through the CreateWorkflow method.  As I stated in class, there is no concept of versioning in a .xoml file and there is no concept of security reading the file in this way either, except for the fact that whoever puts the .xoml file on the machine where the host reads it from must have permissions to do so.

  2. Use .Net versioning techniques where you modify the version in the assembly.cs file prior to deploying it. This should allow in process workflows to continue/finish execution and new workflows to startup with the new workflow version.

 


Here is a link to assembly versioning steps in .Net:


http://msdn2.microsoft.com/en-us/library/51ket42z(vs.71).aspx


 


So, that was the executive summary, but even within these two types of versioning tactics, there are some other things to consider:


 



  1. Are you trying to modify the workflow object structure (ie. Add new dependency properties or methods) or are you trying to add/remove activities?  If you only need to add/remove activities in certain workflow instances, you can still use the WorkflowChanges class to modify these at runtime.  If you are add/removing/changing properties etc of a workflow then you cannot expect a workflow that is currently persisted to be able to be reloaded into a new object structure.

  2. Are you going to be providing workflows or workflow apps to your customers or internal groups and then later wanting to enhance these workflows, without changing the one they have? If you need to do this, it might make more sense to come up with some sort of rules based workflow where you can modify the rules, storing the rules in a database such as we saw with the External Ruleset Demo tool. You can of course change the workflow and rules using the WorkflowChanges class but this only changes the workflow for that one running instance of the workflow, meaning that you would take a performance hit each time you ran the workflow because it would have to be modifying the running workflow instead of executing a compiled version.

  3. If you are going to be using XAML activation, are you going to be linking it to an activity class library? Without using some activity library, just using XAML activation is going to severely limit what you can do with your .xoml file. Since most business logic needs to take place in code, this will most likely mean the code will need to be in a custom activity, which will need to be linked inside of the .xoml file.  So, essentially when you need to update the activity assembly you are once again looking at having to use .Net assembly versioning techniques.

 


 


So, how does an persisted, unloaded workflow know which version of the assembly to use when it is reloaded?  When the workflow gets serialized to the database serialized (binary), the assembly and type information gets serialized as well.  This is normal .NET serialization (BinaryFormatter), not anything workflow-specific.  Upon deserialization,  .NET will automatically load the correct assembly based on version (assuming the correct version of the assembly exists in the GAC or config and can be resolved).


 


The workflow runtime actually knows nothing about workflow versions or any of that.  The instant we serialize a workflow, it’s no longer WF – it’s .NET from then on up to the point after the WF is deserialized again.



Comments (2)

  1. sle98@hotmail.com says:

    Hi,

    Can you kindly give us an example of how to versioning workflow using GAC, side-by-side assemblies? I tried to version my .xoml via side-by-side assemblies in the GAC, but it kept rigidly pointing to either one version, but not all versions as it should. I add the reference assembly via the web.config pointing only one highest version. If I add all of the versions, the clr states that duplicated objects/references found.

    I appreciate for this post, but can you go one step further in illustrating this. Thank you very much.

  2. Larry Wall says:

    A couple of questions:

    1. You say you are trying to version your .xoml workflows so I’m assuming here you have these .xoml workflows inside of your assemblies right?

    2. How are you hosting your workflow? Sounds like IIS but does that mean you have your workflow exposed as a WCF and you are hosting via IIS?

    When I have done this in the past, I had to change the version of the assembly in the assembly.cs file and then deploy that to the GAC. Not sure why yours keeps going to the highest version because the unloaded workflow should have the information it needs to find the correct version.

    I would suggest posting the details above of this problem on the MSDN workflow forum at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=122&SiteID=1 to see if others have seen the same thing.  There are quite a few MVPs plus Microsoft product team folks that monitor that site (plus me).

Skip to main content