Using Workflow Foundation Rules Engine beyond Workflow ...

Most people are aware that Workflow Foundation is a massively powerful flexible toolset to allow you to build workflow based applications.  In true golden hammer style, once you have used it you will be surprised just how many problems look like they need to be solved with workflow!  What you may have missed is that part of the delivery is a very powerful rules engine that can easily be used outside of workflow applications.

In an effort to keep this post short I will keep it very simple and demonstrate how easy it is to use the rules engine outside of the context of workflow activities.

Before you start make sure you have .NET 3.0 installed (, installed the Visual Studio 2005 extensions for WF ( and finally make sure you have read the excellent introduction to the rules engine by Jurgen Willis

The simplest way to create a RuleSet is to use the RuleSetDialog in the System.Workflow.Activities.Rules.Design namespace to create and edit a RuleSet. The dialog is supplied a context object on construction - basically the type is reflected to see what is available for the intellisense on the editor dialog.  To use the RuleSetDialog you need to reference the System.Workflow.Activities and System.Workflow.ComponentModel assemblies.


The RuleSetDialog allows you to define rules which are constructs similar to a basic If-Then-Else programming structure, with the condition and actions defined in an expression language based on the CodeDom model (read Jurgens article for more description).  Basically you can access properties and methods on you context object, and static methods on any class referenced within the host assembly.


The RuleSet is serialisable (to XAML), so dead easy to create persist and reload collections of rules - you can work this bit out for yourself.

To execute a RuleSet you use the RuleEngine in the System.Workflow.Activities.Rules namespace.  You supply it an instance of your object and then Execute and off it goes.


As you can see in this somewhat traditional bogus example, the rule checks for a literal value on a property of the context object, setting it to a different value if true.

Bogus though the example is, it doesn't take much imagination to picture how the rules engine can be harnessed to create massively powerful and extensible apps - with rules persisted outside of the app and editable by users that are able to operate on and affect data within your objects!  Get me a nail I have a new hammer...