In his comments on my blog post regarding development of a SharePoint state machine workflow, Fred Morrison raises an excellent point which I think is worthy of some exposition. Here it is:
In general, when developing task-related activities in SharePoint workflows, code to activity instances (rather than the workflow template).
In a number of the examples available on the Internet (including ones I’ve done), references to the task information (Task ID and various TaskProperties classes) are done declaratively in the properties pane of Visual Studio:
There’s a good reason why this may not typically be the best approach for task-related activities in SharePoint workflows, however. Fred mentions it in his comment: when using the replicator activity or dynamically creating tasks via some other method, you will want your task-related activities to be referencing the properties related to the activity instance and not a public field or property on the workflow.
So what does that look like in practice?
Well, in the MethodInvoking handler for a CreateTask activity, for example, the refactored code looks like this:
Note that the code now references only the instance passed in by the "sender" argument and doesn’t rely on any public members of the workflow class.
The MethodInvoking handler for the associated OnTaskChanged activity gets a new look, as well:
Again, note that the AfterProperties are coming from the event args passed into the method (the ExternalDataEventArgs class in this example) and not from a member of the workflow class. (And while It’s not shown here, you can reference the BeforeProperties in the same way.)
This may not be the right approach for every workflow activity, but I think it’s a pretty good pattern for the ones that relate to SharePoint tasks. Thanks for the insight, Fred.
