Can i upgrade the code of "custom activity" of a persisted workflow wf4

Question

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.

Answer 1

Hi,

->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?

http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/9ac06ba7-21c9-4357-b304-5c57407052ee

Thanks.

---

Leo Tang [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

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.

Tim

Answer 3

Tim 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)?

Answer 4

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.

http://code.msdn.microsoft.com/site/search?query=%22Dynamic%20Update%22&f%5B0%5D.Value=%22Dynamic%20Update%22&f%5B0%5D.Type=SearchText&ac=8

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.
Tim