I was playing around with a state machine workflow in WF and ran across something that I didn’t except. Apparently if you have a an activity that can be other than a singleton, e.g. inside of a loop or as part of a state machine workflow, then an activity can not be accessed by it’s workflow instance variable. For example, the following works just fine in a sequence workflow:

public partial class Workflow2 : SequentialWorkflow {
private void code1_ExecuteCode(object sender, EventArgs e) {
// Retrieve Comment property from typed event sink (generated by wca)
string comment = this.eventSink1.Comment;
    Console.WriteLine("Order approved w/ comment= {0}", comment);
  }
}

However, in the case where the activity can be executed more than once, it’s my understand that each time through, there’s a new activity object that’s different from the named activity associated with the workflow. To get a hold of the current activity, you have to traverse the activity tree, which you can access in a code activity via the sender’s parent property:

public partial class StateMachine1 : StateMachineWorkflow {
void code2_ExecuteCode(object sender, EventArgs e) {
// Retrieve Comment property from typed event sink (generated by wca)
    Code codeActivity = (Code)sender;
    IOrderService_Events.OrderApproved eventSink2 =
      (IOrderService_Events.OrderApproved)(codeActivity.Parent.Activities["eventSink1"]);
    string comment = eventSink2.Comment; // eventSink1.Comment will be unbound
    Console.WriteLine("order approved w/ comment= {0}", comment);
  }
}

I haven’t figured out whether this makes sense to me yet, but that’s how it is. You can get the code.

If you downloaded the samples from my previous two forays into WF communications programming, you probably couldn’t get them to build. The problem is that when I packaged things up, I removed the bin directories. I haven’t figured out just why this causes everything to stop building, but with the help of Dennis Pilarinos, I rearranged the two projects into three:

1. communications interface (CommunicationLibrary): the data exchange service interface definition, compiles into CommunicationLibrary.dll

2. communications activities (WorkflowProject1): uses a pre-build step to generate the typed activities generated from the communications library using the wca tool, references CommunicationLibrary.dll and compiles into WorkflowProject1.dll (nice name, eh? : )

3. application (EventSinkAndMethodInvoke2): the app that uses the typed activities, references both CommunicationLibrary.dll and WorkflowProject1.dll

It’s only by separating the communications activities into a separate assembly that things can build and rebuild reliably. You can download the newly configured code here. Enjoy.

Sure, sure, Alan Cooper and Anders Hejlsberg are keynoting, but I’m the “with” at this year’s Redmond, WA Patterns & Practices Summit 12/13 - 12/15. I don’t yet know what that means, but maybe if I’m enough “with it” in Redmond, it’ll lead to “with-ness” in Sydney or Oslo (hint, hint… : ).

I decided to go a little meta for this year’s XML DevCon:

10. Top 10 List of Top 10 List of Top 10 List Ideas (a little too meta)

9. Top 10 Reasons that XAML Uses XML (Couldnt figure out a good representation of gradients in EDI)

8. Top 10 Secrets of the CLR (Boxing was almost called Richtering)

7. Top 10 Members of the XML Community Least Likely To Fit In At Burning Man (I don’t want to see Doug Purdy showing up at the ice tent in his thong…)

6. Top 10 Members of the XML Community Most Likely To Fit In At Burning Man (Wasnt Rory born at Burning Man?)

5. Top 10 Similarities Between Team America Characters and XML Community Members (XML: Heck yeah!)

4. Top 10 Reasons That Raw XML Programmers Exhibit More Animal Magnetism Than, Well, Anyone Else (Tim Ewald is really all the evidence we need…)

3. Top 10 New Enterprise Features in Visual Studio Orcas (Clippy: It looks like youre designing an insurance agency schema. Can I help you with that?)

2. Top 10 Reasons Democrats Are More Likely To Be XML Programmers Than Republicans (89% of the angle brackets should not go to the top 1% of programmers!)

1. Top 10 Reasons That The Red Sox Are Going To Kick Butt! (Just pandering to the crowd…)

Chris Sells (with help from Scott Hanselman, Tim Ewald, Matt Powell and Scott Bloom)
Applied XML Developer’s Conference
Friday, October 20th, 2005