Probably I have some understanding problem of WF

Zhuang,

Is this only occuring on the dynamic update, or when you're re-loading an already dynamically updated workflow?

If you have any code snippets or stack traces of the failure that'd help too.

Arjun

ArjunBanker at 2007-9-10 >

Zhuang,

After you update the workflow and re-publish the assembly, it sounds like you're overwriting the old assembly to which the persisted instance referred to. To properly handle this, you should use .NET versioning and increment your workflow assembly version before deploying it to the GAC. That way, when the persisted instance is reloaded, the runtime will locate the correct assembly. Note that this only applies to workflow updates made at design-time, when you recompile and publish an updated assembly. If you're only using dynamic update to modify an instance, you don't need to worry about these assembly versioning issues.

Arjun

ArjunBanker at 2007-9-10 >

It won't destroy all running workflows, it just requires you to version your production workflow assemblies.

That said, I totally agree with you, it would be real nice to be able to change persisted workflows to match a new version of the workflow, thus only requiring the latest workflow assembly. It will become a real troubleshooting nightmare when you start having 4-5+ assembly versions in the GAC and have problems with older persisted workflows.

If anyone has ideas on how to approach this, it would be appreciated.

Thanks Jeff

Esprit at 2007-9-10 >