DynamicProxy rocks!

Recently, I've had a need to create proxy objects in two unrelated projects. What they had in common was that they both dealt with .NET Remoting. In one it was traditional Remoting between machines, in the other working with multiple AppDomains for Assembly flexibility. In both scenarios, I had a need for additional proxies other than the Remoting created Transparent proxy and the Castle project's DynamicProxy proved invaluable and versatile. It's a bit sparse on documentation, but for the most part, you should be able to figure things out by playing with it and lurking around their forum.

If you're not familiar with the Castle project, check it out, because DynamicProxy is really only a supporting player in an excellent collection of useful tools. From their Inversion of Control Containers MicroKernel/Windsor to MonoRail and ActiveRecord (built on NHibernate), there is a lot there that can make your life easier.

But why would I need to create proxies, when the Remoting infrastructure in .NET takes care of this for you with Transparent Proxies? Well, let me describe both scenarios:

Resilient Client/Server operations with Remoting

From my experience with .NET Remoting, it's dead simple to do something simple. But it really is best suited for WebService stateless calls, because there isn't a whole lot exposed to add quality of service plumbing. The transparent proxy truly is transparent until something fails. Same is true on the server side, where you don't get a lot of insight into the clients connected to you.

And then there are events, which, imho, are one of the greatest thing about doing client/server programming with Remoting. Those are painful in two ways, having to have a MarshalByRefObject helper proxy the event calls and pruning dead clients on the server which you won't find out about until you try to invoke their event handler.

But those shortcomings are not enough reason to fall back to sockets and custom/stateful wire protocols. Instead I like to wrap my transparent proxy in another proxy that has all the plumbing for maintaining the connection, pinging the server and intelligently handling failure. Originally I created them by hand, but I just converted my codebase over to use DynamicProxy the other day.

Using CreateInterfaceProxyWithoutTarget and having the proxy derive from my plumbing baseclass automagically provides me with an object that looks like my target interface by wraps the Remoting proxy with my quality of service code.

public static RemotingClient<T> GetClient(Uri uri)
{
  Type t = typeof(T);
  ProxyGenerator g = new ProxyGenerator();
  ProxyGenerationOptions options = new ProxyGenerationOptions();
  options.BaseTypeForInterfaceProxy = typeof(RemotingClient<T>);
  RemotingClient<T> proxy = 
    (RemotingClient<T>)g.CreateInterfaceProxyWithoutTarget(
      t, new Type[0], options, new ProxyInterceptor<T>());
  proxy.Uri = uri;
  return proxy;
}

I'll do another post later just on Remoting, since the whole business of getting events to work was a bit of a labor and isn't documented that well.

Loading and unloading Assemblies on the fly

The second project started with wanting to be able to load and unload plug-ins dynamically and has now devolved into a framework for auto-updating components of an App at runtime.

This involves loading the assemblies providing the dynamic components into new AppDomains, so that we can unload the assemblies again by unloading the AppDomain. Instances of the components class are then marshaled across the AppDomain boundary by reference so that the main AppDomain never loads the dynamic assembly. This way, when a component needs to be updated, I can dump that AppDomain and recreate it.

The resilience of the connection isn't in question here, although there is need for quite a bit of plumbing to get references to the remoted components disposed before the AppDomain can be unloaded. Again, a DynamicProxy can help on the main AppDomain side by acting as a facade to the actual reference, so that you can reload the underlying assembly and recreate the reference without the main application having to be aware of it.

But I haven't gotten that far, nor have I decided whether that would be the best way, rather than an explicit disposal and recreation of the references.

Where DynamicProxy comes to a rescue here is when your object to be passed across the boundary isn't derived from MarshalByRefObject. This could be a scenario, where you are trying to use a component that's already derived from another baseclass, so adding MarshalByRefObjectisn't an option. Now DynamicProxy with its ability to provide a baseclass for the proxy gives you a sort of virtual multiple inheritance.

This is also an ideal scenario for using Castle.Windsor as the provider of the component. Using IoC, I was able to create a generic common dll that contains all the interfaces as well as a utility class for managing the components that need to be passed across the boundary, this class never has to know anything about the dynamic assembly, other than that the assembly stuffs its components into the AppDomain's Windsor container.

The resulting logic for creating an instance that can be marshaled across AppDomain boundaries looks something like this:

public T GetInstance<T>()
{
  Type t = typeof(T);
  if (!t.IsInterface)
  {
    throw new ArgumentException("Type must be an interface");
  }
  try
  {
    T instance = container.Resolve<T>();
    if (typeof(MarshalByRefObject).IsAssignableFrom(instance.GetType()))
    {
      return instance;
    }
    else
    {
      ProxyGenerator generator = new ProxyGenerator();
      ProxyGenerationOptions generatorOptions = new ProxyGenerationOptions();
      generatorOptions.BaseTypeForInterfaceProxy = typeof(MarshalByRefObject);
      return (T)generator.CreateInterfaceProxyWithTarget(t, instance, generatorOptions);
    }
  }
  catch (Castle.MicroKernel.ComponentNotFoundException)
  {
    return default(T);
  }
}

All in all, DynamicProxy is something that really should be part of the .NET framework. Proxying and Facading patterns are just too common to only support them via the heavier and MarshalByRefObject dependent remoting infrastructure.

The version of DynamicProxy I was using was DynamicProxy2, which is part of the Castle 1.0 RC3 install. It's a lot more versatile than the first DynamicProxy and deals with generics, but mix-ins are not yet implemented in this version. However, if you just need a single mix-in, specifying the base class for your proxy can go a long way to solving that limitation.