BenK95781

sorry for the bombardment of questions.

Anyway i have read that workfkow uses the binary serializer , in the past this serializer would write the exact type into the data and would fail to deserialize an indentical class with a different dll version. While not an issue with paramaters like string , it is an issue for user defined types like Address.

So what happens if we do this

Persist the workflow

Upgrade server with new version of dll's

Rehydrate the old workflow

What is the normal way of handling this

Regards,

Ben



Re: Windows Workflow Foundation Workflow serialization and system upgrades

Sebastian Kralemann

Hi Ben!

To handle this Microsoft introduced assembly versioning! If you have a look in the persistence database scheme you can see that each persisted workflow has a version info attached.

If you make changes to your workflow you have to increment your assembly version (e.g. 1.0.0.0 -> 1.0.0.1).

In order to deserialize your "old" and new workflow versions the persistence service needs both versions of your assembly. So, you have to install both assembly versions in the GAC so that the assemblies can be found!

Bye,

Sebastian





Re: Windows Workflow Foundation Workflow serialization and system upgrades

BenK

Thanks Sebastian ,

Quite valuable information . This basically means if you want to load old workflows and not use the GAC you need to reference 2 dlls with the same name but different versions. Does this work Have you done it

Im not too worried about very old data as i can get that via a report DB i am concerned however about outstanding workflows when we upgrade versions.

I can image It creates a few build issues how have people managed this . Do they just install every dll in the GAC so after a few years you have 20 version of each dll

Regards,

Ben





Re: Windows Workflow Foundation Workflow serialization and system upgrades

Sebastian Kralemann

Hi Ben!

You have to worry about versioning only if you upgrade while there are instances running or you are using the tracking service! If you want to use the tracking information of your "old" workflow versions you need the matching assembly. Otherwise you receive exceptions when working with the tracking API classes.

The GAC is the best way (although I am not a friend of the GAC *g*) to solve this issue!
You are right, after several upgrades you will have a lot of different versions of your assembly in the GAC.

If you don't want to use the GAC you will have a problem, because you can't have two versions of your assembly in the filesystem. If you increment the version number the assembly's filename, e.g. MyWorkflow.dll, stays the same. To work around this you could deploy your different workflow versions in subdirectories of your application which consumes the workflow, e.g. c:\MyConsumingApp\Workflow_v1.0.0 and c:\MyConsumingApp\Workflow_v1.0.1. Then your app is not able to find your workflow assembly because it is outside the standard assembly lookup directories. Therefore you have to subscribe the AppDomain.AssemblyResolve event and explicitly load the workflow assembly from the correct directory using your directory naming pattern.

I hope this helps!

Bye,
Sebastian




Re: Windows Workflow Foundation Workflow serialization and system upgrades

BenK

Hi Sebastian thanks,

Im looking at about 10K-20K instance per day and they will last 2-10 days so their will always be some in memory. I think once a workflow is finished i will save the results to a reporting DB is this a good pattern

The GAC sounds best , though AssemblyResolve does sound interesting.

Regards,

Ben





Re: Windows Workflow Foundation Workflow serialization and system upgrades

Plop69

Sebastian Kralemann wrote:
Hi Ben!

If you want to use the tracking information of your "old" workflow versions you need the matching assembly. Otherwise you receive exceptions when working with the tracking API classes.


Bye,
Sebastian

I'm having this situation. So i add the old tracking service, and i also have a new tracking service. Now i have following problem:

My old workflows find their corresponding trackingservice, and the tracking goes fine, but my new created workflows track everything twice, so they use the old & new trackingservice. How can i make sure the new workflows only use the new trackingservice, not the old one, because the old one is added just to make sure the old workflows can track their info. Or how should i handle this situation