MS developer network

I'm looking for guidence and best practices for defining workflow properties.  I've seen examples and comments where workflow properties are defined as normal .NET properties.  I've seen an equal number of examples and comments that use dependency properties within the workflow.  I know that you need dependency properties within custom activites in order to permit design time binding to other activities.  What about the workflow properties?  When do I need dependency properties in my workflow?  When can I just use normal .NET properties?  What "features" do I give up if I don't use dependency properties?  Are the benefits or problems with either approach?Thanks in advance.Bruce BukovicsAuthor of .NET 2.0 Interoperability Recipeshttp://www.apress.com/book/bookDisplay.html?bID=10116

Hi Bruce,
The three main reasons for using DependencyProperty over a normal .NET property are:
Activity data-binding
Defining activity metadata
Attached properties
I think it's pretty clear why you need dependency properties to leverage ActivityBind functionality, so I won't go into this topic here.
One key feature that dependency properties carry is defining metadata properties.  An activity metadata property is a property whose value is immutable at runtime - this property can only be assigned a value during design time.  This is extremely useful in situations where changing a property's value at runtime would violate certain assumptions or functionality.  Some examples of metadata properties are the 'Name' and 'Enabled' properties on all activities.  Another key gain of metadata properties is that since their value is immutable at runtime, there is no need to serialize these properties as part of workflow persistence, which reduces the persistence footprint.  Below is an example of a metadata property.
public static readonly DependencyProperty MyMetadataProperty     = DependencyProperty.Register(          "MyMetadata",          typeof(string),          typeof(Workflow1),          new PropertyMetadata(DependencyPropertyOptions.Metadata));
Attached properties is another feature acquired by using dependency properties.  A dependency property that is defined using the 'RegisterAttached' method is referred to as an attached dependency property.  These properties can be set on activities that do not define this property as an extension to their existing property set.  One example is the ConditionedActivityGroup (CAG) 'WhenConditionproperty.'  This property, of type ActivityCondition, is set on all children of CAG in order for CAG to determine the execution pattern for its children.  The children need not define or know about the CAG property because it is specific to CAG, but they can carry the value for this property that CAG defines.  Below is an example of an attached property:
public static readonly DependencyProperty MyAttachedProperty     = DependencyProperty.RegisterAttached(          "MyAttached",          typeof(string),          typeof(Workflow1));
As for defining dependency properties on your workflow, that all depends on your use cases.  A workflow is really no different than a custom activity.  Perhaps your workflow will execute as the root activity in some scenarios, in which case any properties it defines are workflow parameters it exposes, and can just as well be either .NET or dependency properties.  But in other cases, maybe this workflow will be an activity in yet a larger workflow, in which case it may be useful to bind the properties to data in this larger workflow, in which case it would be useful to define them as dependency properties.  It all depends on how exensible you need your 'root' activity to be.
Overall, chances are that if you do not need functionality beyond that of a .NET property, then you probably don't need a dependency property.
-Angel

Hi Bruce,
The three main reasons for using DependencyProperty over a normal .NET property are:
Activity data-binding
Defining activity metadata
Attached properties
I think it's pretty clear why you need dependency properties to leverage ActivityBind functionality, so I won't go into this topic here.
One key feature that dependency properties carry is defining metadata properties.  An activity metadata property is a property whose value is immutable at runtime - this property can only be assigned a value during design time.  This is extremely useful in situations where changing a property's value at runtime would violate certain assumptions or functionality.  Some examples of metadata properties are the 'Name' and 'Enabled' properties on all activities.  Another key gain of metadata properties is that since their value is immutable at runtime, there is no need to serialize these properties as part of workflow persistence, which reduces the persistence footprint.  Below is an example of a metadata property.
public static readonly DependencyProperty MyMetadataProperty     = DependencyProperty.Register(          "MyMetadata",          typeof(string),          typeof(Workflow1),          new PropertyMetadata(DependencyPropertyOptions.Metadata));
Attached properties is another feature acquired by using dependency properties.  A dependency property that is defined using the 'RegisterAttached' method is referred to as an attached dependency property.  These properties can be set on activities that do not define this property as an extension to their existing property set.  One example is the ConditionedActivityGroup (CAG) 'WhenConditionproperty.'  This property, of type ActivityCondition, is set on all children of CAG in order for CAG to determine the execution pattern for its children.  The children need not define or know about the CAG property because it is specific to CAG, but they can carry the value for this property that CAG defines.  Below is an example of an attached property:
public static readonly DependencyProperty MyAttachedProperty     = DependencyProperty.RegisterAttached(          "MyAttached",          typeof(string),          typeof(Workflow1));
As for defining dependency properties on your workflow, that all depends on your use cases.  A workflow is really no different than a custom activity.  Perhaps your workflow will execute as the root activity in some scenarios, in which case any properties it defines are workflow parameters it exposes, and can just as well be either .NET or dependency properties.  But in other cases, maybe this workflow will be an activity in yet a larger workflow, in which case it may be useful to bind the properties to data in this larger workflow, in which case it would be useful to define them as dependency properties.  It all depends on how exensible you need your 'root' activity to be.
Overall, chances are that if you do not need functionality beyond that of a .NET property, then you probably don't need a dependency property.
-Angel

Thank you Angel for your clear summary.Bruce