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 https://msdn2.microsoft.com/En-US/library/aa349375.aspx.
However, out on the forum https://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:
- 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.
- 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:
https://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:
- 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.
- 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.
- 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.
![]() |