I’ve created an extension method to Find Sibling Activity by name
Based on example from http://msdn.microsoft.com/en-us/magazine/cc163414.aspx
public static TActivity FindSiblingActivity<TActivity>(this Activity sender,string activityName) where TActivity:Activity
{
//CodeActivity thisActivityInstance = sender as CodeActivity;sender.
Activity parent = sender.Parent;
var retActivity=parent.GetActivityByName(activityName) as TActivity;
Debug.Assert(sender.IsDynamicActivity==retActivity.IsDynamicActivity,” EXPECTED BOTH BE DYNAMIC”);
return retActivity;
}
Related links http://geekswithblogs.net/mnf/archive/2009/04/21/workflow-activities-should-be-referred-by-sender-object-or.aspx
http://codeidol.com/other/essential-windows-workflow-foundation/Advanced-Activity-Execution/Activity-Execution-Context/
Category Archives: Workflow
Extension method to find root Parent Workflow of current activity
/// Get root Parent Workflow of current activity
/// <returns></returns>
public static Activity FindRootWorkflow(this Activity activity)
{
List<string> list = new List<string>();
Activity act = activity;
while (act != null)
{
if (act.Parent==null)
{
return act;
}
act = act.Parent;
return null;
}
Refer to Activity from workflow in the same project.
“The project type is not supported by this installation” for Workflow project
Download from ActivityExecutionContext in Workflows
Using of Workflow Dependency properties.
The primary advantage to dependency properties is that they allow binding of property values to instance data at runtime. For example, you can bind the input property of one activity to an output property of another. The actual property values resulting from the binding is determined at runtime. Dependency properties are required when you want to bind properties from one activity to another. However, if you are binding an activity property to a workflow property, the workflow property is not required to be a dependency property. In this case, a normal C# property on the workflow class works fine.
Workflow Activities should be referred by sender object or e.Activity, not by activity property name
Important extracts from the article:
this.delayActivity1.TimeoutDuration = TimeSpan.FromSeconds(iterationCount);
((DelayActivity)sender).TimeoutDuration = TimeSpan.FromSeconds(iterationCount);
// RIGHT CODE
CallExternalMethodActiivty act = e.Activity.GetActivityByName(“createTask1”, true) as CallExternalMethodActivity;
act.ParameterBindings[“userName”].Value = e.InstanceData;
Use sender or e.Activity instead of this. e.Activity is the clone of the replicator’s template. Second, we have passed the parameter true to GetActivityByName. This tells the method to look only in the context of the activity on which it was called. This keeps the method from walking into other parts of the tree and returning the RootContext instance.
The issue also described in “Pro WF” By Bruce Bukovics access activities in a context safe way section and in ActivityExecutionContext in Workflows article.
Note, that IsDynamicActivity Property can be used to determine was activity spawned or is executing within the default ActivityExecutionContext of the workflow instance.
I hope that Microsoft will change the syntax of event handlers to separate workflow templates and instances to avoid these not-intuitive errors or at least will generate warnings if code is not context-safe(see my MS connect suggestion).
Windows Workflow: Debugging Limitations.
In Visual Studio Debugger for Windows Workflow Foundation you MUST set the workflow DLL project as the Visual Studio solution startup project to debug the workflow using F5
Documented in http://msdn.microsoft.com/en-us/library/bb483186.aspx
It is not intuitive restriction.
I’ve posted to MS Feedback that it will be good to support workflow Debugging from any startup project.
Recently I’ve noticed, that if workflow DLL project is a startup project, it doesn’t support Edit&Continue in a code dlls. Another thing that MS should improve. It’s similar to ASP.Net Web Site limitation of Edit&Continue.
I also not able to open activity from call-stack- see my post Windows Workflow: Concatenate all parents QualifiedNames- instead of call stack
Windows Workflow: Use of ConditionedActivityGroup activity
- Rule conditions are included in the declarative model and can be dynamically updated at run-time
- The .rules file provides code separation and enables external analysis /tools to be built on top of the .rules file.
Editing declarative conditions in Workflow Designer is too slow.
Also VS “find references” could NOT see the references from rule conditions, which make development harder.
Windows Workflow: Concatenate all parents QualifiedNames- instead of call stack
MSDN Debugging Workflows tells that
The entries in the Call Stack window are a depth-first search of executing activities. You can double-click an entry to put focus on the selected activity.-It doesn’t work for me.
The text on stack trace is not meaningful, when activities are described.
> codeRaiseEvent_ExecuteCode(object sender = {codeRaiseEvent_CAGPNRIterate [System.Workflow.Activities.CodeActivity]}, System.EventArgs e = {System.EventArgs}) Line 671 C#
System.Workflow.ComponentModel.dll!System.Workflow.ComponentModel.Activity.RaiseEvent(System.Workflow.ComponentModel.DependencyProperty dependencyEvent, object sender = {codeRaiseEvent_CAGPNRIterate [System.Workflow.Activities.CodeActivity]}, System.EventArgs e = {System.EventArgs}) + 0xb0 bytes
System.Workflow.Activities.dll!System.Workflow.Activities.CodeActivity.Execute(System.Workflow.ComponentModel.ActivityExecutionContext executionContext) + 0x35 bytes
System.Workflow.ComponentModel.dll!System.Workflow.ComponentModel.ActivityExecutor<System.__Canon>.Execute(System.__Canon activity, System.Workflow.ComponentModel.ActivityExecutionContext executionContext) + 0x2b bytes
System.Workflow.ComponentModel.dll!System.Workflow.ComponentModel.ActivityExecutor<System.__Canon>.Execute(System.Workflow.ComponentModel.Activity activity, System.Workflow.ComponentModel.ActivityExecutionContext executionContext) + 0x32 bytes
System.Workflow.ComponentModel.dll!System.Workflow.ComponentModel.ActivityExecutorOperation.Run(System.Workflow.ComponentModel.IWorkflowCoreRuntime workflowCoreRuntime) + 0xbe bytes
I’ve created a function, that can be called to output trace in case of exception”
/// <summary>/// Concatenate all parents QualifiedNames
/// </summary>
/// <param name=”activity”></param>
/// <returns></returns>
public static string FullQualifiedName(this Activity activity)
{
Activity act=activity;
List<string> list = new List<string>();
while (act != null)
{
list.Insert(0,act.QualifiedName);
act=act.Parent;
}
return CollectionsHelper.ToString<string>(list, “.”,“”);
}
Unrelated note that to debug the workflow using F5 you MUST set the workflow DLL project as the Visual Studio solution startup project.
Developers should avoid smart-quotes in Word
@echo Change name of Database server if required
@echo press control-Z to stop batch
@pause
sqlcmd -S localhost -E -Q “create database WorkflowTracking”
c:
cd “C:WINDOWSMicrosoft.NETFrameworkv3.0Windows Workflow FoundationSQLEN”
sqlcmd -S localhost -E -d WorkflowTracking -i Tracking_Schema.sql
sqlcmd -S localhost -E -d WorkflowTracking -i Tracking_Logic.sql
@echo Ensure that application account has tracking_reader and tracking_writer roles
sqlcmd -S localhost -E -Q “create database WorkflowTracking”.