Category Archives: Workflow

SharePoint TechFest 2009 – Dallas, TX

I want to thank everyone who attended my session on SharePoint Workflow with Visual Studio at our TechFest event yesterday.  Please feel free to post any comments (good or bad) about my presentation or the event. 

Demo source code is posted on Nakido until the Techfest site is updated with session content.

SharePoint WorkFlow with Visual Studio – Downloads

SharePoint WorkFlow with Visual Studio – References


  del.icio.us it! digg it! reddit! technorati! yahoo!

Visual Studio 2008 Workflow Project Wizard – SharePoint Not Installed

Problem:

I’m creating a SharePoint Sequential Workflow using Visual Studio 2008 (SP1) with .Net 3.5 SP1 installed.  This is on a Windows 2003 R2 VPC with SharePoint 2007 (MOSS Enterprise) installed on the local machine for development.  A Collaboration Portal is installed on a web site with host headers (portal) assigned to port 80.

When I create a new workflow project, the wizard asks for a path to the SharePoint site.  I type in my url (http://portal in my case), and the project wizard fails, saying “SharePoint server not installed. Please run Microsoft Office SharePoint Server 2007 setup.”  

VS2008WF-SharePointNotInstalled

I’m logged in as the farm administrator.  I thought it might be a permissions issue (my farm admin doesn’t have full rights on the domain), so I went back and gave it full Domain Admin rights in case that was the problem.  Still failing!!

What the hell?

Resolution:

It turns out that the wizard does some funny business behind the scenes, calling the database directly.  When I give my development account (farm admin) account full rights (dbo) to the SharePoint content database for my portal site, bingo!  Works like a champ. 

After only an hour or two spinning my wheels.  Sigh….


  del.icio.us it! digg it! reddit! technorati! yahoo!

SharePoint – WSPBuilder Workflow Failed On Start

Building a SharePoint 2007 workflow using WSPBuilder and Visual Studio 2008.  Love, love, love the WSPBuilder tool, but the workflow templates could use some work.  Ran into this one today…

Problem

I was receiving “Failed on Start (retrying)” errors.  SharePoint logs showed “The workflow failed validation” exceptions.  This usually means a problem with the .rules files associated with a Declarative Rule Condition.  

I changed my While activities to use code conditions instead, and the problem went away.  But I really wanted to find the source of the issue.  After much trial and error and fruitless searches on the web, I finally found it.  Turns out, it was a missing import target declaration in the .csproj file created by WSPBuilder when I created a workflow project using the “WSPBuilder Workflow with Workflow” project template.

Resolution

To fix the problem, opened up the project file and added the missing import target line (in green), below. Evidently, this line tells studio to include the .rules in the assembly.

     <Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” />
     <Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets” />

Reopened the project, recompile, build wsp, redeploy.  Bingo!  Now my workflow works with Declarative Rule Conditions, as it should!

Credits

Thanks to Greg G’s post here that pointed me in the right direction.


: del.icio.us it! digg it! reddit! technorati! yahoo!

WPF / WF – What Is A Dependency Property?

A new type of property, called a dependency property, was added to the .Net Framework with the release of .Net 3.0.  Dependency properties are used in both Windows Presentation Foundation (WPF) and Workflow Foundations (WF).  They are very similar in both frameworks, but are used for different purposes.

Dependency properties provides the plumbing for property value resolution, change notification, data binding, styling, validation, etc. for properties exposed in Windows Presentation Foundation (WPF) UI elements and Workflow Foundations (WF) custom activities.  Each dependency property is registered with a central repository that handles the change event notifications for you. 

Key Point – The Value of Dependency Properties Are Resolved

The ultimate goal of a dependency property, like any property, is to manage state.  But unlike normal .Net properties, the local property value is not stored in an instance variable. 

Instead, dependency properties are registered with the dependency property framework, and the underlying property value is resolved – meaning the value is determined by the dependency property framework based on rules defined by the property registration.

How To Create A Dependency Property

All WPF UI elements and Workflow Activities are derived from a high-level base classes called DependencyObject, which provides the basic functionality required to implement dependency properties.

public class MySampleControl : Control
{
    // Step 1: Register the dependency property 
    public static readonly DependencyProperty SpecialBrushProperty =
            DependencyProperty.Register("SpecialBrush", typeof(Brush), 
            typeof(MySampleControl));

    // Step 2: Provide set/get accessors for the property
    public Brush SpecialBrush
    {
        // IMPORTANT!!
        // -----------
        // Dependency property accessors should not include custom logic 
        // because the framework may call the base.GetValue() and 
        // SetValue() methods directly
        get { return (Brush)base.GetValue(SpecialBrushProperty); }
        set { base.SetValue(SpecialBrushProperty, value); }
    }
}

As show in the code, there are two steps involved in creating a dependency property:

  1. Create a static field to hold a DependencyProperty object
    • By convention, the field should be named with the normal property name, followed by a “Property” suffix
    • This field will not contain the value of the property.  It simply defines the property that is registered with the dependency system
    • This field should be defined as a public, static, read-only field
      • The property must be available at all times, possibly shared among classes
      • The field is defined with the read-only keyword, meaning it can only be set in the static constructor of the type.
    • The field must be instantiated with a call to the static DependencyPropert.Register() method, passing:
      • The name of the property
      • The type of the property 
      • The type of the class that owns the property

      • Optionally, metadata used to define how the property is treated by the WPF framework
        • Meta-data flags to specify how the property affects the layout of the element (AffectsMeasure, AffectsArrange, AffectsRender, etc.)
        • Callbacks for handling property value changes (PropertyChangedCallback)
        • Callbacks to define custom value logic (CoerceValueCallback) 
        • Callbacks to validate values (ValidateValueCallback)
      • Optionally, metadata used to define how the property is treated by the WF framework
        • Include DependencyPropertyOptions enumerated value to specify additional characteristics for the property (ReadOnly, MetaData, etc.)
  2. Create property accessors (get / set)
    • Call DependencyProperty.SetValue() and GetValue() methods to set local values
    • DependencyObject is a high-level framework base class for WPF UI elements and WF activities
    • DependencyObject exposes the GetValue() and SetValue() methods

Isn’t That A Lot of Code for a Property?

At first glance, yes, this looks like an extremely complicated way to declare a property.  OK, at second glance, it’s still pretty complex.  But once you understand the power of dependency properties provide, especially in the Windows Presentation Framework (WPF), they’ll become a welcome addition to your coding toolbox. 

The convention takes a little getting used to. But after you’ve created a few, it comes quite naturally.  Visual Studio also includes some snippets to help add dependency properties:

  • Insert Snippet > NetFX30 > Define a DependencyProperty
  • Insert Snippet > Other > Workflow > DependencyProperty > Property

Subtle Differences Between in WPF and WF

While WPF and WF both use a similar dependency property frameworks, they are not identical!!

WPF UI elements and WF activities derive from a base DependencyObject class, and use a DependencyProperty class to register properties and get/set property values.  Despite the shared names, they are not the same classes!!

  • DependencyObject and DependencyProperty classes used by WPF reside in the System.Windows namespace
  • DependencyObject and DependencyProperty classes used by WF reside in the System.Workflow.ComponentModel namespace

Though their usage and function are very similar, they are not directly related to one another.

How are Dependency Property Values Resolved?

Property values for dependency properties are resolved automatically by the framework according to the following order of precedence:

  1. Property system coercion
  2. Active animations or animations with a hold behavior (WPF)
  3. Local value
  4. TemplateParent template properties (WPF)
  5. Implicit style (WPF)
  6. Style triggers (WPF)
  7. Template triggers (WPF)
  8. Style setters (WPF)
  9. Default (theme) style (WPF)
  10. Inheritance
  11. Default value from dependency property metadata

Note that the local value is 3rd in the order of precedence.  This means that a property may have a value, even if a local value for the property has never been set.  Also, if a property does have a local value, it may be overridden by higher level precedence items like an animation or data binding.

When Should I Use Dependency Properties In WPF?

Dependency properties are one of the most important concepts within WPF.  In WPF, dependency properties are required to support:

  • Data Binding
  • Animation
  • Styling
  • Value expressions
  • Property invalidation
  • Per-type default values

In short, it makes sense to expose dependency properties any time you expose a property for a custom UI element or control. 

When Should I Use Dependency Properties In WF?

Dependency properties are not used as heavily in Workflow Foundations (WF) as they are in Windows Presentation Foundation (WPF) , but they are still an important part of the WF framework.  They are used primarily when developing custom workflow activities that expose properties to support the following scenarios:

  • Activity Binding
    • This is the most common use of dependency properties in WF
    • Allows activities to expose properties that can be used to bind state to another activity
    • For example, binding the input of one workflow activity to the output of another workflow activity
  • Attached Properties
    • Attached properties are used to create a parent activity that can manage the state of it’s child activities
    • For example, the Conditioned Activity Group can attach a When property to each child
  • Meta Properties
    • Meta properties are defined by including new PropertyMetadata(DependencyPropertyOptions.Metadata) in the DependencyProperty.Register() method call 
    • Meta properties are set at design time and cannot be changed at run-time

    • Meta properties exist to guarantee the integrity of an activity
    • For example, at runtime, you can’t change the InterfaceType of an CallExternalMethod activity because InterfaceType is a meta-property

Sources

  del.icio.us it!

digg it!

reddit!

technorati!

yahoo!