venerdì 9 marzo 2012 11:56
Hi to all.
I know that between WF3.5 and WF4 there are some difference in the way that .NET persist a WF Instance.
My scenario is always related to IIS/AppFabric Host.
- In WF3.5 the engine save the context and the definition/code for every wf instance.
- In WF4 the engine save only the context and not the definition/code
If this is true, when i will change the code of a "custom activity" that is located, in the wf tree, after the persist point (like a replay activity) i should get this scenario:
- WF3.5: nothing happens, the WF execute the oldest code
- WF4.0: the WF execute the new code
is this assumption correct?
This assumption is also true if i insert a Bookmark inside a NativeActivity?
Tnk a lot.
Tutte le risposte
lunedì 12 marzo 2012 08:47Moderatore
->is this assumption correct?
"Unfortunately, there isn't much you can do to resume a persisted instance by using a new workflow definition in .Net Framework4.0. However, in .Net Famework4.5 there are new APIs that will allow you to update the persisted instance to prevent this."
Is my understanding not correct?
mercoledì 14 marzo 2012 06:00Moderatore
It's not a good general assumption, there are some cases that can work, and some that can't.
[corrections and clarifictions in bold]
If your activity is not currently bookmarked (no instance state persisted). In both .Net 4.0 and .Net 4.5 you can safely make bigger implementation changes to your activity, compared to if it currently has instance state persisted at an idle point.
But even then.... In .Net 4.0 you definitely cannot change any of your arguments, variables, or child activities (as declared by CacheMetadata). In .Net 4.5, with dynamic update, you may be able to deploy code with those changes in combination with performing a dynamic update.
Now if instead you are talking about an activity which is 'currently bookmarked' (instance state is persisted while the workflow is at an idle point) you can do code changes but it is much more difficult, they have to made into safe non-breaking change to e.g. make a minor bugfix in an Execute() method or similar - doing anything else easily can fall afoul of state serialization issues or bookmark resumption issues.
In .Net 4.0
-you should probably not change the public signature (properties) of your activity class at all.
-you must not change the names or signatures of delegate functions used in bookmark resumption callbacks in your activity because it will cause problems with bookmark resumption (public or not)
-you must not change your activity's other instance state, such as execution properties
In .Net 4.5
-you may be able to make changes which were unsafe in .Net 4.0, but it still requires work in terms of defining dynamic update logic to figure out the safe way of resuming your changed workflow, and fixup the bits of your activity which interface with the workflow runtime and it's knowledge of your persisted state.
- Modificato Tim Lovell-SmithModerator mercoledì 14 marzo 2012 06:00
- Modificato Tim Lovell-SmithModerator mercoledì 14 marzo 2012 21:56 clarifications and corrections
- Modificato Tim Lovell-SmithModerator mercoledì 14 marzo 2012 21:57
- Modificato Tim Lovell-SmithModerator mercoledì 14 marzo 2012 21:58
- Modificato Tim Lovell-SmithModerator mercoledì 14 marzo 2012 21:58 corrections and clarifications
- Contrassegnato come risposta LeoTangModerator domenica 18 marzo 2012 03:51
mercoledì 14 marzo 2012 15:04Tim are you saying that you can not use the dynamic update feature in .net 4.5 with a state machine workflow that is persisted with bookmark(s)?
mercoledì 14 marzo 2012 21:49Moderatore
I may have described that rather badly, I shouldn't necessarily have mixed Dynamic Update with non-breaking code changes to activity code, so I'll try to edit the above to try to clarify.
In State Machine's case for instance, it's not actually State Machine that creates bookmarks, it's only the child activities, and state machine is quite permissive with what dynamic updates are allowed.
I can see there's also a hunger for better understanding of Dynamic Update here. It so happens that our WF PMs like Hani have posted some Dynamic Update samples on code.msdn.microsoft.com.
It's a complex thing to explain, but basically when you're using Dynamic Update you're able to rewrite the workflow's interface with a runtime in the way the runtime understands, and get around many of the things that just won't work in WF 4.0.