Again, some background on where we are with rules in WF version 1 (in .NET FX 3.0):
The Rules framework in WF allow you to define discrete and atomic rules using simple semantics. This makes it very approachable. WF Rules distinguish conditions (boolean evaluations) and rules (if-then-else semantics, where the if-part uses a condition). There are several out-of-the-box activities that use conditions (IfElse, While, Replicator, Conditioned Activity Group (CAG)), and one Policy activity that works with a RuleSet, consisting of multiple rules. Obviously, custom activities allow you to use both conditions and rules.
The conditions and rules are defined in XAML format, as a XML representation of a CodeDOM object model for the IL that will eventually be executed. By default, the XAML is defined in a .rules file, embedded in the assembly as a manifest resource file. The default editor allows you to build the rules in a C# or VB-like language (side note: the “VB-like” language is a running gag at Class-A, where Mike Glaser coined this term during a Analysis Services training). These two flavors are as close to C#/VB as possible, but still an invention of the WF team. There is a document here that describes the differences (link and document will be up as soon as I get it from Moustafa Khalil Ahmed).
You can use tracking and tracing when working with rules. The RuleActionTrackingEvent tracks a rule name and the result of the condition evaluation. Rules condition evaluation is implicitly tracked by activity execution. All you need to do is build a tracking profile and listen for the user tracking events related to rules. This tracking is only available for rules executed from within a workflow. Tracing is provided by the Diagnostics API and involves nothing more than adding the tracing source for WF rules to your config file. This also means that (in contrast to tracking) rules tracing is available everywhere.
This is where we are at in v1.
Orcas rule changes involve an enhanced language support. In particular, there is support for
- operator overloading
- new operator
- calling of extension methods.
Furthermore, WF includes bugfixes on bugs that have been reported so far.
As an example, take a look at this ELSE action of an imaginary rule that validates the order information:
Notice how the new operator is used. Then imagine that the ReportErrors method is actually an extension method. Calling it will work as expected.
So, my take on this is that there aren’t many enhancements available in the Workflow rules. Just good things like the bugfixes and the extra bits of language support.
The WF team is planning for the post-Orcas release, but there are no concrete plans yet, at least not any that Moustafa would tell about (as they might change).