Archive for September, 2009


WPF binding to a Windsor proxied component

WPF binding is very powerful but has some annoying issues. This time I faced with a well known one: binding to an explicitly implemented interface member doesn’t work:

public interface IFoo {
int BarsCount {get;}

public class Foo:IFoo {
int IFoo.BarsCount {
return 3;

<TextBox DataContext=[set to some Foo instance] Text={Binding Path=BarsCount} />

This way the textbox is not filled; while annoying, it could be fixed implementing interface implicitly:

public class Foo:IFoo {
public int BarsCount {
return 3;

Sometimes it is not possible, because we can’t control concrete class implementation. This is the case when the concrete class is dynamically generated proxy.

In a project of mine I use Castle Project’s Windsor Container, that relies on Castle DynamicProxy for its AOP/intercepion features (which I use for cross-cutting concern implementation).
In this project all the presenters are registered in the container with related interfaces; when I configure an interceptor for a presenter, the concrete class returned by the container is not the registered implementation, but a dynamically generated proxy (implementing the registered interface) forwarding all method calls to a wrapped instance of my hand-written presenter (thus allowing methods interception).

This interception style is called Interface Proxy  (see excellent Krzysztof Koźmic tutorial on Castle DynamicProxy proxy capabilities).

This way, however, previously working binding to the presenter stops running: presenter instance no longer has expected (at least by WPF) properties in its public interface.

The solution I found (yet not very general) is to leverage another interception style, Class Proxy, used by Windsor when a component is registered without a corresponding interface. In this scenario, the generated proxy is a dynamically generated subclass of the concrete component registered; this way only virtual method could be intercepted, but the public interface of the component is preserved (and so the WPF binding operation).

The choice of the interception style is taken by a well defined (and pluggable) Windsor component: IProxyFactory. So I implemented a custom IProxyFactory, inheriting the default one and altering its behavior when the registered component is decorated with a certain custom attribute; this attribute specifies that a Class Proxy style interception should be used. Here the implementation:

public class ForceClassProxyAttribute : Attribute { }

//Force class proxy if service implementor is decorated with ForceClassProxyAttribute
//Is a workaround for WPF binding not seeing interface members
public class WindsorProxyFactory : DefaultProxyFactory
public override object Create(Castle.MicroKernel.IKernel kernel, object target, Castle.Core.ComponentModel model, Castle.MicroKernel.CreationContext context, params object[] constructorArguments)
if (this.ShouldForceClassProxy(model, target))
return CreateForcingClassProxy(kernel, target, model, context, constructorArguments);
return base.Create(kernel, target, model, context, constructorArguments);

protected virtual object CreateForcingClassProxy(Castle.MicroKernel.IKernel kernel, object target, Castle.Core.ComponentModel model, Castle.MicroKernel.CreationContext context, params object[] constructorArguments)
object proxy;

IInterceptor[] interceptors = ObtainInterceptors(kernel, model, context);

ProxyOptions proxyOptions = ProxyUtil.ObtainProxyOptions(model, true);
ProxyGenerationOptions proxyGenOptions = CreateProxyGenerationOptionsFrom(proxyOptions);

CustomizeOptions(proxyGenOptions, kernel, model, constructorArguments);

Type[] interfaces = proxyOptions.AdditionalInterfaces;
proxy = generator.CreateClassProxy(model.Implementation, interfaces, proxyGenOptions,
constructorArguments, interceptors);

CustomizeProxy(proxy, proxyGenOptions, kernel, model);

return proxy;

protected bool ShouldForceClassProxy(Castle.Core.ComponentModel model, object target)

return model.Implementation
.GetCustomAttributes(typeof(ForceClassProxyAttribute), true)

Then I simply provide this custom IProxyFactory implementation when container instance is created:

var container = new WindsorContainer(new IniziativeInformatiche.Core.WindsorProxyFactory());

Comments and suggestions are welcome, if someone will ever get here 🙂


It seems that binding to interface members could be done with the syntax:

{Binding Path=(local:IFoo.BarsCount)}

I should better investigate, even though this way I should fix all existing views…


Stock Trader with Caliburn – code repository

I set up a project repository to publish the code:


Stock Trader with Caliburn /3

It’s time to give the project some love, and put down some code to fix ideas.I created a new solution and started to transfer feature one after one.

I kept the overall structure of the original project  to simplify comparison between the two implementation and because I found it quite neat. The two project created are the exe project, containing the shell, and an Infrastructure library, containing common interfaces and classes (just like the original StockTraderRI):


The first step I decided to take is to setup the project structure and have the shell starting.

Original application doesn’t have a presenter for the shell, so I created an IShellPresenter interface in Infrastructure proejct (I’ll need to reference it in the modules) and an implementation in the exe project:


The Singleton attibute is used to auto-register the class within the container with a singleton lifestyle; the View attribute indicates Caliburn which view should be used to “visually represent” the presenter.
The markup for the shell view (ShellView.xaml) was only slightly modified to remove reference to CompositeWPF library and to custom controls,  whose features will be implemented later.

To have the first window running, I had to configure Caliburn. I chosen to derive my App class from CaliburnApplication, so I just had to indicate the  root model for the application:


That’s all. I can start the application and the main window shows as well (with no content, for now):


Next time I’ll add the first real feature of the app; since all feature in original StockTraderRI resides in modules, I also have to deal with module loading and configuration.
I also should setup an online code repository to share the code.


Stock Trader with Caliburn /2

Time to put down a plan of the porting work (not a schedule: I wouldn’t even try it; the time I could give to this project is little and, even worse, very uncertain).

Stock Trader is composed of the subsequent parts:

  • an infrastructure library (StockTraderRI.Infrastructure) containing interfaces, classes and conventions shared between the various modules;
  • the application executable (StockTraderRI) containing the shell and all the code needed to glue together the modules;
  • four modules (StockTraderRI.Modules.Market, StockTraderRI.Modules.News, StockTraderRI.Modules.Position, StockTraderRI.Modules.WatchList) implementing the various features of the application.

Here is an architectural overview of the system, from Microsoft’s documentation.

I intend to keep the overall structure unchanged, and focus on technical implementation details regarding module management and UI composition. I would like to emphasize the implementation differences of the same real-world challenges illustrated in the original Stock Trader RI.


Prism Stock Trader… with Caliburn

Some months ago, I started using Composite Application Guidance (Prism, for friends) to build a modular composite application in WPF.

I liked the overall architecture, yet I was not very comfortable with it; I hated, mainly, the need of a lot of  plumbing code between the application parts.

After that, I discovered Caliburn. I was scared, at first, to afford the learning curve for another framework, but after little attempts I completely changed my mind: Caliburn is quite easy to start with and has smart solutions to eliminate plumbing code. It encourages the use of conventions and has plenty customization hooks.

I’ve been using Caliburn for a while; now I would like to port the Stock Trader application (the Prism reference implementation) to Caliburn, with the aim of comparing difference in style, complexity and raw line of code.

Stay tuned!



First step done.

In the last weeks I finally decided to take the time to open a blog, mainly focused (for now, at least) on .Net programming.

My main goals are:

  • share thoughts, ideas, suggestion about technical .Net stuff (and hopefully receive some feedback);
  • improve my poor English;
  • use some of my (scanty) spare time for a long-term task.

I hope this will become an interesting space. Wish me to succeed!

September 2009
    Oct »

%d bloggers like this: