Update: Moved the RSS to FeedBurner. Please re-update

I’ll be attending Microsoft Developer Academy 4.0 (Hebrew-only site, sorry). I’ll take a stab at blogging live from the event (wireless coverage permitting). See you around!

Update: Got myself a Twitter account @dudnet.

P.S. I didn’t abandon the PropertyChange series; the third article is to be published soon. In the meantime, check out some derivaciónes

1. INotifyPropertyChanged AOP
2. IDataErrorInfo AOP
3. Policy Injection
4. Performance and optimizations
5. The final solution

I hope you will find this useful in your work; all feedback will be greatly appreciated.

The previous article discussed an implementation of the INotifyPropertyChanged aspect using Unity Interception AOP. Today we will see how a similar approach can be applied to another interface commonly used by WPF (as well as by ASP.NET MVC).

The IDataErrorInfo interface consists of two methods:

1. an indexer accepting a property name (columnName) parameter and
2. an Error property.

We will solely focus on the indexer, which returns error messages on a per-property basis.

The Validation Application Block allows developers to easily incorporate input validation via property attributes and/or application configuration, supporting a variety of provided validators, as well as custom ones.

IDataErrorInfo and VAB seem to be a perfect match, and have indeed been integrated. Adding Unity Interception will further simplify input validation, so that (presentation) models could be specified in the following manner:

[NotifyPropertyChanged, DataErrorInfo]
public class Contact : MarshalByRefObject, INotifyPropertyChanged, IDataErrorInfo
{
    [StringLengthValidator(1, 20, MessageTemplate="First name length must be between {3} and {5}.")]
    [ContainsCharactersValidator("0123456789", Negated = true, MessageTemplate = "First name cannot contain digits.")]
    public string FirstName { get; set; }

    [StringLengthValidator(1, 20, MessageTemplate = "Last name length must be between {3} and {5}.")]
    [ContainsCharactersValidator("0123456789", Negated = true, MessageTemplate = "Last name cannot contain digits.")]
    public string LastName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    public string Error
    {
        get { return null; }
    }

    public string this[string columnName]
    {
        get { return null; }
    }
}

Note: The implementation presented below is limited to classes derived (possibly indirectly) from MarshalByRefObject.

Project

In addition to Microsoft.Practices.Unity.Interception, we will require a reference to Microsoft.Practices.EnterpriseLibrary.Validation, which is listed as Enterprise Library Validation Application Block under the .NET tab in Visual Studio (provided the Enterprise Library is installed).

Matching Rules

We will be intercepting

1. getters of indexers accepting a single string parameter
2. defined in types decorated with DataErrorInfoAttribute:
   

   [Serializable, AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
   public class DataErrorInfoAttribute : Attribute { }

The second rule is best defined using CustomTypeAttributeMatchingRule.

The first rule could be defined using MethodSignatureMatchingRule by specifying get_Item as the methodName. However, (yet another) custom matching rule seems more appropriate. This time, we will reuse some code from MethodSignatureMatchingRule and PropertyMatchingRule:

public class IndexerMatchingRule : IMatchingRule
{
    private readonly List<Glob> patterns = new List<Glob>();
    private readonly List<TypeMatchingRule> parameterRules = new List<TypeMatchingRule>();

    public IndexerMatchingRule(PropertyMatchingOption option, IEnumerable<string> parameterTypeNames)
        : this(option, parameterTypeNames, false)
    {
    }

    public IndexerMatchingRule(PropertyMatchingOption option, IEnumerable<string> parameterTypeNames, bool ignoreCase)
    {
        if (option != PropertyMatchingOption.Set)
            patterns.Add(new Glob("get_Item"));
        if (option != PropertyMatchingOption.Get)
            patterns.Add(new Glob("set_Item"));

        foreach (string parameterTypeName in parameterTypeNames)
            parameterRules.Add(new TypeMatchingRule(parameterTypeName, ignoreCase));
    }

    public bool Matches(MethodBase member)
    {
        if (!member.IsSpecialName || !patterns.Exists(delegate(Glob pattern) { return pattern.IsMatch(member.Name); }))
            return false;

        ParameterInfo[] parameters = member.GetParameters();
        if (parameters.Length != parameterRules.Count)
            return false;

        for (int i = 0; i < parameters.Length; ++i)
            if (!parameterRules[i].Matches(parameters[i].ParameterType))
                return false;

        return true;
    }
}

Call Handler

Our call handler will be pretty compact.

public class DataErrorInfoItemCallHandler : ICallHandler

ICallHandler members:

    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
        IMethodReturn res = getNext()(input, getNext);

        string propertyName = input.Arguments.Count > 0 ?
            input.Arguments[0] as string :
            null;

        res.ReturnValue = GetError(input.Target, propertyName);

        return res;
    }

    public int Order { get; set; }

Lines 7-9 provide a sanity check, so that the handler won’t throw an exception when invoked incorretly (i.e. without a string argument).

    private ValidationResults GetError(object target, string propertyName)
    {
        MethodInfo validateGen = validate.MakeGenericMethod(target.GetType());
        ValidationResults results = (ValidationResults)validateGen.Invoke(null, new object[] { target });
        if (results.IsValid)
            return string.Empty;

        return string.Join("\n", results.Where(r => r.Key == propertyName).Select(r => r.Message).ToArray());
    }

    private static readonly MethodInfo validate = typeof(Validation).GetMethods().First(m => m.Name == "Validate");

While the reference to Validation.Validate() is constant, we need to obtain a type-specific (“generic”) version per target type. Multiple validation messages are concatenated with newlines inserted between them.

In the next article we will update our implementation to support the Policy Injection Application Block and see several deployment and usage scenarios. Stay tuned!

1. all the WPF stuff (barring WPF User Control) is hidden in Add New Item menus/dialogs,
2. no fine-tuning of project types is provided and
3. TFS doesn’t make recreating a project an easy task,

so I created a new WPF User Control Library project and compared between the two.

Now, if you need to add WPF capabilities to your Control Library, just follow these simple instructions:

1. Open the .csproj file in your favorite text editor (no, VS won’t do )
2. Under the first <PropertyGroup> element add:

       <ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

3. If (VS.version >= 2010) add:

       <TargetFrameworkProfile>Client</TargetFrameworkProfile>

4. Save changes.
5. Reload in VS.

Hey VS team, great obfuscation job!

Background

If you have ever developed a non-trivial application in WPF, you’ll probably find this familiar:

    public class ProductFamilyViewModel : INotifyPropertyChanged
    {
        private bool isSelected;
        public bool IsSelected
        {
            get { return isSelected; }
            set
            {
                if (isSelected != value)
                {
                    isSelected = value;
                    SendPropertyChanged("IsSelected");
                }
            }
        }

        private bool isExpanded;
        public bool IsExpanded
        {
            get { return isExpanded; }
            set
            {
                if (isExpanded != value)
                {
                    isExpanded = value;
                    SendPropertyChanged("IsExpanded");
                }
            }
        }

        private bool isActive;
        public bool IsActive
        {
            get { return isActive; }
            set
            {
                if (isActive != value)
                {
                    isActive = value;
                    SendPropertyChanged("IsActive");
                }
            }
        }

        private void SendPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }

(This is an excerpt from a real class I’ve been working on; the actual code is bigger and uglier.)

Isn’t it sad that you have auto-implemented properties, but not the ability to use them? Wouldn’t you love to be able to do something like that?

[NotifyPropertyChanged]
public class ProductFamilyViewModel : MarshalByRefObject, INotifyPropertyChanged
{
    public bool IsSelected { get; set; }
    public bool IsExpanded { get; set; }
    public bool IsActive { get; set; }
    public event PropertyChangedEventHandler PropertyChanged;
}

This has been achieved (with varying levels of success) with DynamicProxy2 and repeatedly with PostSharp (reportedly refined in PostSharp 2.0), but what about Microsoft Enterprise Library?

At first, the Policy Injection Application Block might look like the perfect tool for the task, but looks are often deceiving; quoting Richard Banks:

Windsor and PIAB both have a shortfall that we can’t overcome.  Neither of them can alter the type of a class they are providing aspects for – they simply provide proxies that add hooks to intercept method calls.  We would still need to implement INotifyPropertyChanged in our class for binding to work.

Not to fret! Luckily, Enterprise Library 4.1 ships with the Unity Application Block (also available as a separate download). Unity, in turn, contains the mighty Interception Extension, which seems to be getting undeservedly little attention from developers. I guess this has to do with its poor documentation and lack of UI configuration support (expected to be added in 5.0).

None of these, however, have prevented Derek Greer from trying. His post contains a great introduction to Unity Interception (Prolegomena is definitely recommended) and quite a few insights, but sadly falls short of achieving the ultimate goal.

This article details a complete user-friendly implementation of the INotifyPropertyChanged aspect using Unity Interception AOP. It is the first in a planned series of articles concerning AOP with Unity Interception and Policy Injection:

1. INotifyPropertyChanged AOP
2. IDataErrorInfo AOP
3. Policy Injection
4. Performance and optimizations
5. The final solution

I hope you will find this useful in your work; all feedback will be greatly appreciated.

Note: The implementation presented below is limited to classes derived (possibly indirectly) from MarshalByRefObject.

Update 2009-12-14: Dima Gershman, a truly knowledgeable colleague of mine, says go with the looks. Policy Injection wraps user objects with Interception’s transparent proxies, relieving us of the burden of manual configuration (and even improving performance!), although that comes at the price of some extra library dependencies. To be continued…

Project

We’ll start by creating a Class Library project and adding the following reference to it:

• Microsoft.Practices.Unity.Interception

Quite a small dependency toll, isn’t it? Using our library will require some additional references (depending on the configuration strategy), which will be detailed below.

Note: Although the assembly name is Microsoft.Practices.Unity.Interception.dll, the namespace is Microsoft.Practices.Unity.InterceptionExtension. This significant source of confusion (especially considering the lack of configuration editor support) will hopefully be eliminated in EntLib 5.0.

Update 2009-12-12: Removed unneeded reference to Microsoft.Practices.Unity.

Matching Rules

Let’s have another look at the desired syntax:

[NotifyPropertyChanged]
class Class1 : MarshalByRefObject, INotifyPropertyChanged
{
    public int MyProperty { get; set; }
    public event PropertyChangedEventHandler PropertyChanged;
}

NotifyPropertyChangedAttribute is the easiest part:

[Serializable, AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
public class NotifyPropertyChangedAttribute : Attribute { }

Update 2009-12-19: Enabled inheritance.

Next, we’ll need to specify the rules to be used to intercept the methods (or setters, in our case), namely

1. public setters
2. defined in types decorated with NotifyPropertyChangedAttribute.

The following matching rule types are provided out of the box:

• AssemblyMatchingRule
• AttributeDrivenPolicyMatchingRule
• CustomAttributeMatchingRule
• MemberNameMatchingRule
• MethodSignatureMatchingRule
• NamespaceMatchingRule
• ParameterTypeMatchingRule
• PropertyMatchingRule
• ReturnTypeMatchingRule
• TagAttributeMatchingRule
• TypeMatchingRule

PropertyMatchingRule is perfect for the first rule; we’ll simply specify * as propertyName and Set as option.

The second rule is a bit trickier.

Let’s look at TagAttributeMatchingRule. This class matches TagAttribute (duh!):

[Tag("NotifyPropertyChanged")]
class Class1 : MarshalByRefObject, INotifyPropertyChanged

However, such approach is prone to typos, since constants cannot be used as attribute parameters.

AttributeDrivenPolicyMatchingRule matches method parameters:

public int MyProperty
{
    get;
    [Notify] set;
}

which is somewhat closer to our requirement, but is still error-prone. Ideally, we’d decorate the entire class with our custom attribute and leave the auto-implemented properties, well, auto-implemented.

This calls for a mix between CustomAttributeMatchingRule, TagAttributeMatchingRule and TypeMatchingRule. How does one interbreed between three different species? Luckily, we’re not in the field of biology, so this is fairly easy:

public class CustomTypeAttributeMatchingRule : IMatchingRule
{
    private readonly Type attributeType;
    private readonly bool inherited;

    public CustomTypeAttributeMatchingRule(Type attributeType, bool inherited)
    {
        if (attributeType == null)
            throw new ArgumentNullException("attributeType");
        if (!attributeType.IsSubclassOf(typeof(Attribute)))
            throw new ArgumentException("The specified type is not a subclass of Attribute", "attributeType");

        this.attributeType = attributeType;
        this.inherited = inherited;
    }

    public bool Matches(MethodBase member)
    {
        if (member == null)
            throw new ArgumentNullException("member");

        object[] attributes = member.ReflectedType.GetCustomAttributes(attributeType, inherited);
        return attributes != null && attributes.Length > 0;
    }
}

The most surprising to me was the fact that nobody (starting with Microsoft) had implemented this beforehand. This is mostly a copy-and-paste job, so I can’t really claim copyright for the implementation, just for the idea

Call Handler

Now that we have the matching rules defined, let’s proceed to the call handler:

public class NotifyPropertyChangedCallHandler : ICallHandler

Implementing the interface methods:

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
{
    bool shouldRaise = ShouldRaiseEvent(input);
    IMethodReturn res = getNext()(input, getNext);
    if (res.Exception == null && shouldRaise)
        RaiseEvent(input);
    return res;
}

public int Order { get; set; }

The event isn’t raised if an exception has been thrown by the setter.

private bool ShouldRaiseEvent(IMethodInvocation input)
{
    MethodBase methodBase = input.MethodBase;
    if (!methodBase.IsSpecialName || !methodBase.Name.StartsWith("set_"))
        return false;

    string propertyName = methodBase.Name.Substring(4);
    PropertyInfo property = methodBase.ReflectedType.GetProperty(propertyName);
    MethodInfo getMethod = property.GetGetMethod();
    if (getMethod == null)
        return false;
    object oldValue = getMethod.Invoke(input.Target, null);
    object value = input.Arguments[0];

    return value == null ?
        value != oldValue :
        !value.Equals(oldValue);
}

First, we make sure that we are dealing with a setter (this part is borrowed from Derek’s class). Then, we use reflection to check that the new value is accessible via a public getter (check added 2009-12-14) and is actually different from the old one. The ternary operator takes care of unboxing.

private void RaiseEvent(IMethodInvocation input)
{
    FieldInfo field = null;
    for (Type type = input.methodBase.ReflectedType;
        (field = type.GetField("PropertyChanged", BindingFlags.Instance | BindingFlags.NonPublic)) == null;
        type = type.BaseType)
        ;

    MulticastDelegate evt = field.GetValue(input.Target) as MulticastDelegate;
    if (evt != null)
    {
        string propertyName = input.MethodBase.Name.Substring(4);
        evt.DynamicInvoke(input.Target, new PropertyChangedEventArgs(propertyName));
    }
}

In order to raise the event, we walk up the inheritance chain in search for the event’s field, cast it to MulticastDelegate and dynamically invoke the delegates.

This concludes our multicast for today. Since design-time configuration calls for a lengthy explanation, we’ll deal with usage in a separate article.

Update 2009-12-14: Added check for public getter.