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 using System; using System.Reflection; using System.Reflection.Emit; namespace Rapid.DynamicProxy.Assembly { /// <summary> /// Class for creating an assembly builder. /// </summary> internal static class DynamicAssemblyBuilder { #region Create /// <summary> /// Creates an assembly builder. /// </summary> /// <param name="assemblyName">Name of the assembly.</param> public static AssemblyBuilder Create(string assemblyName) { AssemblyName name = new AssemblyName(assemblyName); AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly( name, AssemblyBuilderAccess.Run); DynamicAssemblyCache.Add(assembly); return assembly; } /// <summary> /// Creates an assembly builder and saves the assembly to the passed in location. /// </summary> /// <param name="assemblyName">Name of the assembly.</param> /// <param name="filePath">The file path.</param> public static AssemblyBuilder Create(string assemblyName, string filePath) { AssemblyName name = new AssemblyName(assemblyName); AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly( name, AssemblyBuilderAccess.RunAndSave, filePath); DynamicAssemblyCache.Add(assembly); return assembly; } #endregion } } 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 using System.Reflection.Emit; using Rapid.DynamicProxy.Exceptions; using Rapid.DynamicProxy.Resources.Exceptions; namespace Rapid.DynamicProxy.Assembly { /// <summary> /// Cache for storing the dynamic assembly builder. /// </summary> internal static class DynamicAssemblyCache { #region Declarations private static object syncRoot = new object(); internal static AssemblyBuilder Cache = null; #endregion #region Adds a dynamic assembly to the cache. /// <summary> /// Adds a dynamic assembly builder to the cache. /// </summary> /// <param name="assemblyBuilder">The assembly builder.</param> public static void Add(AssemblyBuilder assemblyBuilder) { lock (syncRoot) { Cache = assemblyBuilder; } } #endregion #region Gets the cached assembly /// <summary> /// Gets the cached assembly builder. /// </summary> /// <returns></returns> public static AssemblyBuilder Get { get { lock (syncRoot) { if (Cache != null) { return Cache; } } throw new RapidDynamicProxyAssertionException(AssertionResources.NoAssemblyInCache); } } #endregion } } 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 using System.Reflection.Emit; using Rapid.DynamicProxy.Assembly; namespace Rapid.DynamicProxy.Module { /// <summary> /// Class for creating a module builder. /// </summary> internal static class DynamicModuleBuilder { /// <summary> /// Creates a module builder using the cached assembly. /// </summary> public static ModuleBuilder Create() { string assemblyName = DynamicAssemblyCache.Get.GetName().Name; ModuleBuilder moduleBuilder = DynamicAssemblyCache.Get.DefineDynamicModule (assemblyName, string.Format("{0}.dll", assemblyName)); DynamicModuleCache.Add(moduleBuilder); return moduleBuilder; } } } 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 using System.Reflection.Emit; using Rapid.DynamicProxy.Exceptions; using Rapid.DynamicProxy.Resources.Exceptions; namespace Rapid.DynamicProxy.Module { /// <summary> /// Class for storing the module builder. /// </summary> internal static class DynamicModuleCache { #region Declarations private static object syncRoot = new object(); internal static ModuleBuilder Cache = null; #endregion #region Add /// <summary> /// Adds a dynamic module builder to the cache. /// </summary> /// <param name="moduleBuilder">The module builder.</param> public static void Add(ModuleBuilder moduleBuilder) { lock (syncRoot) { Cache = moduleBuilder; } } #endregion #region Get /// <summary> /// Gets the cached module builder. /// </summary> /// <returns></returns> public static ModuleBuilder Get { get { lock (syncRoot) { if (Cache != null) { return Cache; } } throw new RapidDynamicProxyAssertionException(AssertionResources.NoModuleInCache); } } #endregion } } 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 using System; using System.Collections.Generic; using System.Security.Cryptography; using System.Text; namespace Rapid.DynamicProxy.Types { /// <summary> /// Cache for storing proxy types. /// </summary> internal static class DynamicTypeCache { #region Declarations static object syncRoot = new object(); public static Dictionary<string, Type> Cache = new Dictionary<string, Type>(); #endregion /// <summary> /// Adds a proxy to the type cache. /// </summary> /// <param name="type">The type.</param> /// <param name="proxy">The proxy.</param> public static void AddProxyForType(Type type, Type proxy) { lock (syncRoot) { Cache.Add(GetHashCode(type.AssemblyQualifiedName), proxy); } } /// <summary> /// Tries the type of the get proxy for. /// </summary> /// <param name="type">The type.</param> /// <returns></returns> public static Type TryGetProxyForType(Type type) { lock (syncRoot) { Type proxyType; Cache.TryGetValue(GetHashCode(type.AssemblyQualifiedName), out proxyType); return proxyType; } } #region Private Methods private static string GetHashCode(string fullName) { SHA1CryptoServiceProvider provider = new SHA1CryptoServiceProvider(); Byte[] buffer = Encoding.UTF8.GetBytes(fullName); Byte[] hash = provider.ComputeHash(buffer, 0, buffer.Length); return Convert.ToBase64String(hash); } #endregion } } 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.
