Using .NET Framework 3.0 WF Activities in .NET Framework 4 with the Interop Activity
The Interop activity is a .NET Framework 4 (WF 4) activity that wraps a .NET Framework 3.5 (WF 3.5) activity within a .NET Framework 4 workflow. The WF 3 activity can be a single leaf activity or an entire tree of activities. The execution (including cancellation and exception handling) and the persistence of the .NET Framework 3.5 activity occur within the context of the .NET Framework 4 workflow instance that is executing.
|Visual Basic Note:|
|The Interop activity does not appear in the workflow designer toolbox unless the workflow's project has its Target Framework setting set to .NET Framework 4.|
Criteria for Using a WF 3 Activity with an Interop Activity
For a WF 3 activity to successfully execute within an Interop activity, the following criteria must be met:
The WF 3 activity must derive from System.Workflow.ComponentModel.Activity.
The WF 3 activity must be declared as
publicand cannot be
The WF 3 activity must have a public default constructor.
Due to limitations in the interface types that the Interop activity can support, HandleExternalEventActivity and CallExternalMethodActivity cannot be used directly, but derivative activities created using the Workflow Communication Activity tool (WCA.exe) can be used. See Windows Workflow Foundation Tools for details.
Configuring a WF 3 Activity Within an Interop Activity
To configure and pass data into and out of a WF 3 activity, across the interoperation boundary, the WF 3 activity’s properties and metadata properties are exposed by the Interop activity. The WF 3 activity’s metadata properties (such as Name) are exposed through the ActivityMetaProperties collection. This is a collection of name-value pairs used to define the values for the WF 3 activity’s metadata properties. A metadata property is a property backed by dependency property for which the Metadata flag is set.
The WF 3 activity’s properties are exposed through the ActivityProperties collection. This is a set of name-value pairs, where each value is a Argument object, used to define the arguments for the WF 3 activity’s properties. Because the direction of a WF 3 activity property cannot be inferred, every property is surfaced as an InArgument/OutArgument pair. Depending on the activity’s usage of the property, you may want to provide an InArgument entry, an OutArgument entry, or both. The expected name of the InArgument entry in the collection is the name of the property as defined on the WF 3 activity. The expected name of the OutArgument entry in the collection is a concatenation of the name of the property and the string “Out”.
Limitations of Using a WF 3 Activity Within an Interop Activity
The WF 3 system-provided activities cannot be directly wrapped in an Interop activity. For some WF 3 activities, such as DelayActivity, this is because there is an analogous WF 4 activity. For others, this is because the functionality of the activity is not supported. Many WF 3 system-provided activities can be used within workflows wrapped by the Interop activity, subject to the following restrictions:
Send and Receive cannot be used in an Interop activity.
WebServiceInputActivity, WebServiceOutputActivity, and WebServiceFaultActivity cannot be used within an Interop activity.
InvokeWorkflowActivity cannot be used within an Interop activity.
SuspendActivity cannot be used within an Interop activity.
Compensation-related activities cannot be used within an Interop activity.
There are also some behavioral specifics to understand regarding the use of WF 3 activities within the Interop activity:
WF 3 activities contained within an Interop activity are initialized when the Interop activity is executed. In WF 4 there is no initialization phase for a workflow instance prior to its execution.
The WF 4 runtime does not checkpoint workflow instance state when a transaction begins, regardless of where that transaction begins (within or outside of an Interop activity).
WF 3 tracking records for activities within an Interop activity are provided to WF 4 tracking participants as InteropTrackingRecord objects. InteropTrackingRecord is a derivative of CustomTrackingRecord.
A WF 3 custom activity can access data using workflow queues within the interoperation environment in exactly the same way as within the WF 3 workflow runtime. No custom activity code changes are required. On the host, data is enqueued to a WF 3 workflow queue by resuming a Bookmark. The name of the bookmark is the string form of the IComparable workflow queue name.