Published Friday, December 01, 2006 3:22 AM by mtaulty

WF and Versioning

I wrote about this before but I thought I'd post some more with a bit of code that I knocked together.

One of the questions which always comes up with WF is about versioning of Workflows. I think that there's at least 3 aspects to this and there's probably more.

The idea is that you design a definition of a Workflow and you then deploy that hosted in some environment. Given that Workflows are intended to last a long time it's possible that you may want to do some of;

  1. Deploy a new version of the Workflow definition (or its Activities) whilst existing definitions are still "active" (i.e. passivated somewhere). This might involve some/all of;
    1. Changing the Activities that make up the Workflow definition or their properties.
    2. Changing the business rules that the Workflow definition makes use of. By default, when you compile in VS the rules get bundled as a resource into the assembly so this becomes another variant of (1) as it still means changing the assembly that contains the Workflow definition.
  2. Make modifications to a Workflow instance whilst it is running. This might involve changing the business rules or logic that the Workflow Instance is using or adding/removing Activities within the instance. This is a runtime capability of the WorkflowRuntime and doesn't involve having to re-deploy anything.
  3. Make modifications to a type such as an interface that is forming the basis of an ExternalDataExchange service that is sitting "between" a Workflow instance and its runtime host. This is effectively like going back to (1) because it means rebuilding the Workflow definition against the new interface definition.
  4. Make modifications to the runtime hosting environment. For instance, the implementation of an ExternalDataExchange interface might change.

 

(2) is a built-in capability of the WorkflowRuntime and (4) should work out ok as long as nothing in the modifications breaks what the passivated Workflows are expecting as behaviour so I thought I'd think a bit about (2) and (3).

I built a Version 1.0.0.0 Workflow definition. This Workflow simply sits in a loop, using a Version 1.0.0.0 ExternalDataExchange interface that looks like this;

 

  [ExternalDataExchange]
  public interface IReportVersion
  {
    void ReportVersion(string s);
  }

 

and the Version 1.0.0.0 Workflow looks like this;

 

 

and it just gets its assembly version number and then keeps calling the host every 15 seconds with it. The host (Version 1.0.0.0) is a Windows Forms application (with persistence service plugged in) which just displays this on the screen;

 

 

I built this out of 4 assemblies;

  1. The host application.
  2. The workflow definition in a library.
  3. An assembly in a library.
  4. An interface that sits between (1) and (2) in a library.

Here's how I made use of this (note that I GAC'd my assemblies for side-by-side);

 

  1. Ran up the application with everything V1.0.0.0. Ran a Workflow and let it run. Closed the application. I now have a V1.0.0.0 workflow instance persisted.
  2. Changed version numbers to 2.0.0.0 on the Workflow, the Activities, the Host Application. Left the version of the interface assembly at V1.0.0.0.
  3. Ran up the application which is now at V2.0.0.0. Started the runtime. Note that the V1.0.0.0 Workflow instance resumes even though this host is built against V2.0.0.0. Note that if I'd changed the interface assembly version then I think this would fail as the passivated Workflow instance is looking for V1.0.0.0. of that ExternalDataExchange service and if it's not still there then that'd be a problem. I think that's a fairly subtle thing but it's important.
  4. Started a V2.0.0.0 workflow in the V2.0.0.0 host. Now I've got 2 Workflow instances running. Closed the application.
  5. Repeated steps (2) to (4) but moved things on to V3.0.0.0

 

I packaged the bits up and dropped them on the website here.

Note that the source I've supplied is for the V3.0.0.0 version and I've just dropped out the binaries for the other ones. Also, note that you need to GAC things (setup.bat). The way you'd run this;

  1. Run setup.bat to GAC the right bits.
  2. Run V1\WorkflowHost.exe and do Start Runtime, Start Workflow and then just close the app.
  3. Run V2\WorkflowHost.exe and spot the V1.0.0.0 Workflow instance is still running and then close the app.
  4. Run V3\WorkflowHost.exe and repeat if you want to.
  5. Note that the Workflow definitions are infinite loops so if you want to get rid of them from your persistence store then use the "Get Rid...." button at some point.

# Link Listing - December 1, 2006 @ Friday, December 01, 2006 8:26 PM

Attend 3 Webcasts, get free software [Via: gduthie ] Video: Debugging ASP.NET AJAX Applications with...

Christopher Steen

# New and Notable 131 @ Thursday, December 14, 2006 1:46 PM

I am SO busy with INETA trips and tons to do at work. Here is what I have stored up for the last week

Sam Gentile

# New and Notable 131 @ Saturday, October 20, 2007 12:26 PM

I am SO busy with INETA trips and tons to do at work. Here is what I have stored up for the last week

Sam Gentile