Creating a dynamic proxy generator – Part 1 – Creating the Assembly builder, Module builder and caching mechanism

I’ve recently started a project with a few mates to learn the ins and outs of Dependency Injection, AOP and a number of other pretty crucial patterns of development as we’ve all been using these patterns for a while but have relied totally on third part solutions to do the magic.

We thought it would be interesting to really get into the details by rolling our own IoC container and hopefully learn a lot on the way, and you never know, we might even create an excellent framework.

The open source project is called Rapid IoC and is hosted at http://rapidioc.codeplex.com/

One of the most interesting tasks for me is creating the dynamic proxy generator for enabling Aspect Orientated Programming (AOP).

In this series of articles, I’m going to track each step I take for creating the dynamic proxy generator and I’ll try my best to explain what everything means - mainly as I’ll be using Reflection.Emit to emit a fair amount of intermediate language code (IL) to create the proxy types at runtime which can be a little taxing to read.

It’s worth noting that building the proxy is without a doubt going to be slightly painful so I imagine there will be plenty of areas I’ll need to change along the way.

Anyway lets get started…

 

Part 1 - Creating the Assembly builder, Module builder and caching mechanism

Part 1 is going to be a really nice simple start, I’m just going to start by creating the assembly, module and type caches.

The reason we need to create caches for the assembly, module and types is simply to save the overhead of recreating proxy types that have already been generated, this will be one of the important steps to ensure that the framework is fast… kind of important as we’re calling the IoC container ‘Rapid’ – will be a little bit embarrassing if we manage to create the slowest framework.

The Assembly builder

The assembly builder is what is used to create an assembly at runtime, we’re going to have two overloads, one will be for the actual use of the proxy generator, the other will be mainly for testing purposes as it will also save the assembly so we can use Reflector to examine the code that has been created.

Here’s the code:

DynamicAssemblyBuilder
  1. using System;
  2. using System.Reflection;
  3. using System.Reflection.Emit;
  4. namespace Rapid.DynamicProxy.Assembly
  5. {
  6.     /// <summary>
  7.     /// Class for creating an assembly builder.
  8.     /// </summary>
  9.     internal static class DynamicAssemblyBuilder
  10.     {
  11.         #region Create
  12.  
  13.         /// <summary>
  14.         /// Creates an assembly builder.
  15.         /// </summary>
  16.         /// <param name="assemblyName">Name of the assembly.</param>
  17.         public static AssemblyBuilder Create(string assemblyName)
  18.         {
  19.             AssemblyName name = new AssemblyName(assemblyName);
  20.  
  21.             AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly(
  22.                     name, AssemblyBuilderAccess.Run);
  23.  
  24.             DynamicAssemblyCache.Add(assembly);
  25.  
  26.             return assembly;
  27.         }
  28.  
  29.         /// <summary>
  30.         /// Creates an assembly builder and saves the assembly to the passed in location.
  31.         /// </summary>
  32.         /// <param name="assemblyName">Name of the assembly.</param>
  33.         /// <param name="filePath">The file path.</param>
  34.         public static AssemblyBuilder Create(string assemblyName, string filePath)
  35.         {
  36.             AssemblyName name = new AssemblyName(assemblyName);
  37.  
  38.             AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly(
  39.                     name, AssemblyBuilderAccess.RunAndSave, filePath);
  40.  
  41.             DynamicAssemblyCache.Add(assembly);
  42.  
  43.             return assembly;
  44.         }
  45.  
  46.         #endregion
  47.     }
  48. }

 

So hopefully the above class is fairly explanatory, an AssemblyName is created using the passed in string for the actual name of the assembly.

An AssemblyBuilder is then constructed with the current AppDomain and depending on the overload used, it is either just run in the current context or it is set up ready for saving.

It is then added to the cache.

 

DynamicAssemblyCache
  1. using System.Reflection.Emit;
  2. using Rapid.DynamicProxy.Exceptions;
  3. using Rapid.DynamicProxy.Resources.Exceptions;
  4.  
  5. namespace Rapid.DynamicProxy.Assembly
  6. {
  7.     /// <summary>
  8.     /// Cache for storing the dynamic assembly builder.
  9.     /// </summary>
  10.     internal static class DynamicAssemblyCache
  11.     {
  12.         #region Declarations
  13.  
  14.         private static object syncRoot = new object();
  15.         internal static AssemblyBuilder Cache = null;
  16.  
  17.         #endregion
  18.  
  19.         #region Adds a dynamic assembly to the cache.
  20.  
  21.         /// <summary>
  22.         /// Adds a dynamic assembly builder to the cache.
  23.         /// </summary>
  24.         /// <param name="assemblyBuilder">The assembly builder.</param>
  25.         public static void Add(AssemblyBuilder assemblyBuilder)
  26.         {
  27.             lock (syncRoot)
  28.             {
  29.                 Cache = assemblyBuilder;
  30.             }
  31.         }
  32.  
  33.         #endregion
  34.  
  35.         #region Gets the cached assembly
  36.         
  37.         /// <summary>
  38.         /// Gets the cached assembly builder.
  39.         /// </summary>
  40.         /// <returns></returns>
  41.         public static AssemblyBuilder Get
  42.         {
  43.             get
  44.             {
  45.                 lock (syncRoot)
  46.                 {
  47.                     if (Cache != null)
  48.                     {
  49.                         return Cache;
  50.                     }
  51.                 }
  52.  
  53.                 throw new RapidDynamicProxyAssertionException(AssertionResources.NoAssemblyInCache);
  54.             }
  55.         }
  56.  
  57.         #endregion
  58.     }
  59. }

The cache is simply a static property that will store the AssemblyBuilder (I know it’s a little weird that I’ve made it public, this is for testing purposes, I know that’s a bad excuse but hey…)

There are two methods for using the cache – Add and Get, these just provide thread safe access to the cache.

 

The Module Builder

The module builder is required as the create proxy classes will need to live inside a module within the assembly.

Here’s the code:

DynamicModuleBuilder
  1. using System.Reflection.Emit;
  2. using Rapid.DynamicProxy.Assembly;
  3. namespace Rapid.DynamicProxy.Module
  4. {
  5.     /// <summary>
  6.     /// Class for creating a module builder.
  7.     /// </summary>
  8.     internal static class DynamicModuleBuilder
  9.     {
  10.         /// <summary>
  11.         /// Creates a module builder using the cached assembly.
  12.         /// </summary>
  13.         public static ModuleBuilder Create()
  14.         {
  15.             string assemblyName = DynamicAssemblyCache.Get.GetName().Name;
  16.  
  17.             ModuleBuilder moduleBuilder = DynamicAssemblyCache.Get.DefineDynamicModule
  18.                 (assemblyName, string.Format("{0}.dll", assemblyName));
  19.  
  20.             DynamicModuleCache.Add(moduleBuilder);
  21.  
  22.             return moduleBuilder;
  23.         }
  24.     }
  25. }

As you can see, the module builder is created on the assembly that lives in the DynamicAssemblyCache, the module is given the assembly name and also a string representing the filename if the assembly is to be saved.

It is then added to the DynamicModuleCache.

DynamicModuleCache
  1. using System.Reflection.Emit;
  2. using Rapid.DynamicProxy.Exceptions;
  3. using Rapid.DynamicProxy.Resources.Exceptions;
  4. namespace Rapid.DynamicProxy.Module
  5. {
  6.     /// <summary>
  7.     /// Class for storing the module builder.
  8.     /// </summary>
  9.     internal static class DynamicModuleCache
  10.     {
  11.         #region Declarations
  12.  
  13.         private static object syncRoot = new object();
  14.         internal static ModuleBuilder Cache = null;
  15.  
  16.         #endregion
  17.  
  18.         #region Add
  19.  
  20.         /// <summary>
  21.         /// Adds a dynamic module builder to the cache.
  22.         /// </summary>
  23.         /// <param name="moduleBuilder">The module builder.</param>
  24.         public static void Add(ModuleBuilder moduleBuilder)
  25.         {
  26.             lock (syncRoot)
  27.             {
  28.                 Cache = moduleBuilder;
  29.             }
  30.         }
  31.  
  32.         #endregion
  33.  
  34.         #region Get
  35.  
  36.         /// <summary>
  37.         /// Gets the cached module builder.
  38.         /// </summary>
  39.         /// <returns></returns>
  40.         public static ModuleBuilder Get
  41.         {
  42.             get
  43.             {
  44.                 lock (syncRoot)
  45.                 {
  46.                     if (Cache != null)
  47.                     {
  48.                         return Cache;
  49.                     }
  50.                 }
  51.  
  52.                 throw new RapidDynamicProxyAssertionException(AssertionResources.NoModuleInCache);
  53.             }
  54.         }
  55.  
  56.         #endregion
  57.     }
  58. }

 

The DynamicModuleCache is very similar to the assembly cache, it is simply a statically stored module with thread safe Add and Get methods.

 

The DynamicTypeCache

To end off this post, I’m going to create the cache for storing the generated proxy classes.

I’ve spent a fair amount of time thinking about the type of collection I should use to store the types and have finally decided that for the time being I’m going to use a generic dictionary.

This may change when I can actually performance test the proxy generator but the time being I think it makes good sense in theory, mainly as it pretty much maintains it’s performance with varying numbers of items – almost constant (0)1.

Plus I won’t ever need to loop through the items which is not the dictionaries strong point.

Here’s the code as it currently stands:

DynamicTypeCache
  1. using System;
  2. using System.Collections.Generic;
  3. using System.Security.Cryptography;
  4. using System.Text;
  5. namespace Rapid.DynamicProxy.Types
  6. {
  7.     /// <summary>
  8.     /// Cache for storing proxy types.
  9.     /// </summary>
  10.     internal static class DynamicTypeCache
  11.     {
  12.         #region Declarations
  13.  
  14.         static object syncRoot = new object();
  15.         public static Dictionary<string, Type> Cache = new Dictionary<string, Type>();
  16.  
  17.         #endregion
  18.  
  19.         /// <summary>
  20.         /// Adds a proxy to the type cache.
  21.         /// </summary>
  22.         /// <param name="type">The type.</param>
  23.         /// <param name="proxy">The proxy.</param>
  24.         public static void AddProxyForType(Type type, Type proxy)
  25.         {
  26.             lock (syncRoot)
  27.             {
  28.                 Cache.Add(GetHashCode(type.AssemblyQualifiedName), proxy);
  29.             }
  30.         }
  31.  
  32.         /// <summary>
  33.         /// Tries the type of the get proxy for.
  34.         /// </summary>
  35.         /// <param name="type">The type.</param>
  36.         /// <returns></returns>
  37.         public static Type TryGetProxyForType(Type type)
  38.         {
  39.             lock (syncRoot)
  40.             {
  41.                 Type proxyType;
  42.                 Cache.TryGetValue(GetHashCode(type.AssemblyQualifiedName), out proxyType);
  43.                 return proxyType;
  44.             }
  45.         }
  46.  
  47.         #region Private Methods
  48.  
  49.         private static string GetHashCode(string fullName)
  50.         {
  51.             SHA1CryptoServiceProvider provider = new SHA1CryptoServiceProvider();
  52.             Byte[] buffer = Encoding.UTF8.GetBytes(fullName);
  53.             Byte[] hash = provider.ComputeHash(buffer, 0, buffer.Length);
  54.             return Convert.ToBase64String(hash);
  55.         }
  56.  
  57.         #endregion
  58.     }
  59. }

As you can see, there are two public methods, one for adding to the cache and one for getting from the cache. Hopefully they should be clear enough, the Get is a TryGet as I do not want the dictionary to throw an exception if a proxy doesn’t exist within the cache.

Other than that I’ve decided to create a key using the SHA1CryptoServiceProvider, this may change but my initial though is the SHA1 algorithm is pretty fast to put together using the provider and it is also very unlikely to have any hashing collisions. (there are some maths behind how unlikely this is – here’s the wiki if you’re interested http://en.wikipedia.org/wiki/SHA_hash_functions)

 

Anyway, that’s the end of part 1 – although I haven’t started any of the fun stuff (by fun I mean hairpulling, teeth grating Relfection.Emit style fun), I’ve got the basis of the DynamicProxy in place so all we have to worry about now is creating the types, interceptor classes, method invocation information classes and finally a really nice fluent interface that will abstract all of the hard-core craziness away and leave us with a lightning fast, easy to use AOP framework.

Hope you find the series interesting.

All of the source code can be viewed and/or downloaded at our codeplex site - http://rapidioc.codeplex.com/

Kind Regards,

Sean.

8 Comments

  • Could you use a RealProxy rather than generating a dynamic proxy by hand? I would be interested to know which way is faster in terms of creation and execution.

  • Excellent piece. I was just looking into dynamic proxy generation for another purpose; this will save me a lot of trial-and-error. Looking forward to the next post.

  • Cheers Mark, the next post should be up in the next few days.

  • Hope you don't mind me asking: are you using Live Writer, and if so, which plug-in do you use to format those code blocks? They look great.

  • Hi Mark,
    I'm using the Paste As Visual Code v1.6 for live writer - Paste As Visual Studio Code v1.6, it looks cool although it's a shame it doesn't make it easy to copy and paste the code from the blog page though.
    Cheers,
    Sean.

  • What is the reason for having the GetHashCode method? It is doubling the hashing, as a dictionary does its own hashing... AssemblyQualifiedName is sufficient to be a key to the cache (precisely, even more correct).

  • Hi Akbyr,
    It's a good question, I could probably have just used the AssemblyQualifiedName without hashing but the dictionaries hashing method doesn't guarantee uniqueness as it can re-use hashes, the SHA1 algorithm goes a lot further towards that goal... it's probably little over-engineering but the overhead is so small i thought I might aswell, having the key's stored as hashes might also help the internal parsing.

  • Hi Akbyr,

    I may revisit this area then on your advice - my biggest challenge at the moment is getting generic byref and out parameters working which I'm finding quite challenging, I have outs and refs working for non-generic types but still struggling constructing the delegates, I think it's because of the appended ampersand causing issues, should hopefully get that working this week though, if you have any ideas on that it would be most appreciated.

    Cheers,

    Sean

Comments have been disabled for this content.