that little Silverlight box left unchecked kept bothering me. So with a little extra effort I made Ditto.AsyncInit and (some of) its upcoming child libraries compatible with Silverlight 5.

Now, don’t get me wrong. I’m fully aware of Silverlight’s current status  if it’s of any indication, Microsoft’s Immutable Collections library, released in mid-2013, targets every possible platform (including Xamarin), but not Silverlight.

However, that old dog can be taught the async/await trick, meaning many developers maintaining existing applications could benefit from asynchronous initialization having taken care of. If you happen to be a Silverlight developer with asynchrony in mind, you may find this article useful. Regardless of your plans of using any of the Ditto.AsyncInit components, you might still be interested in some of the challenges I encountered while making them compatible with Silverlight.

Unlike Stephen Cleary’s original example, our implementation conveys a more realistic delay. Let’s assume that we’re able to come up with a server that’s actually capable of running this code. We’re now bound to deal with particularly impatient end users refusing to wait for the computation to complete. What we need is a way for our service to respond to cancellation requests.

Although this is a somewhat contrived example, cancellation is a very serious issue that needs to be addressed in most real-life scenarios.

Update 2014-11-30: The second and the third article in the series provide important updates. Please consider reading them before using code from this article.

The Problem

The Task-based Asynchronous Pattern introduced in .NET Framework 4.5 provides developers with a streamlined syntax for consuming asynchronous tasks and operations. WinRT takes it to the extreme by effectively forcing the developers to incorporate TAP in their code.

This leaves us with the problem of asynchronous constructors, or, more precisely, lack thereof. Stephen Cleary had a great write-up a while ago (more recently republished as part of his MSDN Magazine series) with a couple of solutions to this problem.

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:

an indexer accepting a property name (columnName) parameter and

an Error property.

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

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

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:

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…