A few weeks ago, there was a post on the Advanced Workflow blog (an excellent resource, which I recommend you take a look at) about spawned contexts and how it affects activities (or rather, code related to activities) nested inside activities such as Replicator, While and so on. This is an issue that can be quite confusing and it's easy to write code that won't work correctly under these circumstances (one of the dangers of writing too much code behind your workflow, I'd say). I've seen a few posts on the Windows Workflow forums from people that have been bitten by this issue, such as this one , and it got me thinking about whether using Activity Binds instead of directly modifying properties of activities in code (event handlers) might simplify this. As far as I can tell, it indeed works just fine under beta 2, and it seems to me like it can lead to a slightly more elegant solution than what I proposed as the solution for that particular post. Here's a similar example that instead defines a read-only property on the workflow class that returns the current member of an enumerator over the collection and then simply binds the relevant property of the activity in the While loop to the workflow property. Works much nicer, I think. private List < MemberInfo > members; private IEnumerator < MemberInfo > enumerator; public MemberInfo CurrentMember { get { return enumerator . Current; } } public Sample2() { InitializeComponent(); members = MemberInfo . GetMembers(); enumerator = members . GetEnumerator(); } private void WhileCondition( object sender, ConditionalEventArgs e) { e . Result = enumerator . MoveNext(); } You can see the code for the example here . Sample1.cs contains the original proposed solution, while Sample2.cs contains the new one using binding. That said, I'm still not totally happy with it. It still requires some code to put everything together and it's not quite as "declarative" as I'd like... Read More...