October 24, 2005
Petzold on “Does Visual Studio Rot the Mind?”
I’m really loving having Mr. Petzold in the blogesphere. His latest essay has the following abstract:
Visual Studio can be one of the programmer’s best friends, but over the years it has become increasingly pushy, domineering, and suffering from unsettling control issues. Should we just surrender to Visual Studio’s insistence on writing our code for us? Or is Visual Studio sapping our programming intelligence rather than augmenting it? This talk dissects the code generated by Visual Studio; analyzes the appalling programming practices it perpetuates; rhapsodizes about the joys, frustrations, and satisfactions of unassisted coding; and speculates about the radical changes that Avalon will bring.
It doesn’t end the way I expected it to. Fun stuff.
October 24, 2005
spout
WF Activity Context
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 here.
October 24, 2005
spout
Typed WF Communications Details
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:
communications interface (CommunicationLibrary): the data exchange service interface definition, compiles into CommunicationLibrary.dll
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? : )
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.