Many times it could happen that you may want to update your definition while you have many workflows already running.
What happens? Well, if you change the definition and then resuming any workflow created with a previous version of the same, then you have 99% probability to get issues/exceptions (Murphy law again!).
This is normal, and I can explain why and how to work around this.
WF4 introduces a new persistence model which reduces the amount of data to serialize when persisting. This was a great improvement against the previous version of the framework because allows the framework to scale up better than previously.
However, it introduces the versioning issue, because if you added/removed some activities from your definition the persistence engine is not able to understand where to resume your workflow as well as the values of the variables/arguments at that stage.
There is also a logical issue behind that. You can’t assume that the new workflow definition is compatible with the new one.
You need to track all the versions of definitions that have running workflows into a table, for instance, and then provide your custom hosting for the workflow runtime so that you can deal directly with persistence engine and load the right version by your own. I already talked about that here:
What is going to come
vNext will include Dynamic Updates on workflow resumption to help on this stuff. So the framework is going to provide a way to automate version redirection or definition “upgrade” automatically for you.
However, I guess “upgrading” can’t be done in any case, depends a lot on the kind of change you made. I think that this new feature will fall back to version redirection when not able to perform upgrade.