使用lambda expression来动态获取delegate，然后用Cecil注入代码（1）
深感一口气吃不成胖子的郁闷……要是时间能停下来让我慢慢想就好了。之前留意到ray_linn在这边的留言，提到AOP的需求：希望能找到一种办法来自动生成待注入的IL，然后利用Mono.Cecil来实现这个注入。Cecil本身功能还不错，但是在插入代码时，必须要自己来组装IL，这对不熟悉IL的开发者来说是个挑战，对熟悉IL的开发者来说也并不总是让人高兴的事吧。最好就是能用什么更高级的语言来编写待注入的代码，例如说使用C#本身。
要把高级语言翻译成IL，无非就是进行了编译的工作。在.NET Framework提供的现成的工具中，有三种办法可以实现这个编译：
1、从外部编译出IL
2、使用System.CodeDom来生成IL
3、使用C# 3.0的lambda expression，配合System.Linq.Expressions.Expression<TDelegate>来生成IL
当然咯，要是有毅力自己写一个编译器也不是不行……时间、精力、毅力，缺一不可。
所以还是把自己写编译器的选项放在一边，看看上面三种选择分别是个什么状况：
1、从外部编译出IL
可以把待注入的代码放在一个特定名字的方法里，从外部让C#编译器编译出整个assembly，然后再通过反射找到那个特定方法，并提取其中的IL。
过程类似这样：
先定义个占位用的接口：
public interface IInjectionWrapper{ void CodeToBeInjected( ); // make an ugly name to avoid name clashing}
然后实现这个接口，并从外部调用csc（.NET Framework的C#编译器）或mcs（Mono的C#编译器）来编译下面的代码，得到一个assembly：
public class CodeInjectionDummy : IInjectionWrapper{ public void CodeToBeInjected( ) { // some code here // for now let's just print some meaningless message System.Console.WriteLine( "Dummy message" ); }}
得到了编译好的assembly之后，另外写一个程序来抽取其中的内容：
using Mono.Cecil;using Mono.Cecil.Cil;// ......// get the dummy assemblyAssemblyDefinition assembly = AssemblyFactory.GetAssembly( "CodeInjectionDummy.dll" );// get the dummy methodMethodDefinition method = assembly.MainModule.Types[ "CodeInjectionDummy" ] .GetMethod( "CodeToBeInjected", new Type[] { } );// do whatever necessary with the instructions// for now let's just print them out...foreach ( Instruction ins in method.Body.Instructions ) { Console.WriteLine( "IL_{0}: {1}\t{2}", ins.Offset.ToString( "x4" ), ins.OpCode.Name, ins.Operand is string ? string.Format( "\"{0}\"", ins.Operand ) : ins.Operand );}
这种办法挺RP的。好处是我们熟悉的开发环境还是可以用，而且错误也会在编译时被捕捉到，但是要从外部调用编译器而不是在程序内部调用，可以控制的程度就降低了。
当然我们可以把待注入的代码的那个dummy类跟进行注入的类放在同一个文件里（或者广义来说，放在同一个assembly），就不用像上面描述的那样分开编译，但本质上还是一样的。
2、使用System.CodeDom来生成IL
例子请看这里。
使用System.CodeDom，我们可以轻松的把C#或者VB.NET的代码编译为assembly。相对前一种方法而言，使用System.CodeDom给予了我们更好的控制力；我们是直接在代码里调用编译器的，而且生成的assembly也不一定要以文件形式保存到磁盘上，而是可以直接在内存生成并使用。
但是问题也很明显：编译用的源代码，要么要以字符串的形式存在，要么要放在别的文件里。如果把源代码放在一个字符串里，那IDE就没办法对那字符串里的内容提供任何语法高亮之类的功能了——那就是一字符串。如果在字符串里打错了点什么，也必须到运行我们对System.CodeDom的调用时才能够发现。如果要把需要注入的源代码放在别的文件里的话，那还不如直接用前一种方法了，反正麻烦程度都差不多……
顺带一提，Sebastien Lebreton所写的Reflexil也是用System.CodeDom来进行代码生成的。具体的代码在/Compilation/Compiler.cs里。
同时，Reflexil也用到了Cecil。下面引用/Utils/CecilHelpers.cs的一段代码（GPLv3）：
#region " Method body import "/// <summary>/// Clone a source method body to a target method definition./// Field/Method/Type references are corrected/// </summary>/// <param name="source">Source method definition</param>/// <param name="target">Target method definition</param>public static void ImportMethodBody( MethodDefinition source, MethodDefinition target ) { // All i want is already in Mono.Cecil, but not accessible. // Reflection is my friend object context = new ImportContext( new DefaultImporter( target.DeclaringType.Module ) ); Type contexttype = context.GetType( ); Type mbodytype = typeof( Mono.Cecil.Cil.MethodBody ); MethodInfo clonemethod = mbodytype.GetMethod( "Clone", BindingFlags.Static | BindingFlags.NonPublic, null, new Type[ ] { mbodytype, typeof( MethodDefinition ), contexttype }, null ); Mono.Cecil.Cil.MethodBody newBody = clonemethod.Invoke( null, new object[ ] { source.Body, target, context } ) as Mono.Cecil.Cil.MethodBody; target.Body = newBody; // Then correct fields and methods references foreach ( Instruction ins in newBody.Instructions ) { if ( ins.Operand is TypeReference ) { TypeReference tref = ins.Operand as TypeReference; if ( tref.FullName == source.DeclaringType.FullName ) { ins.Operand = target.DeclaringType; } } else if ( ins.Operand is FieldReference ) { FieldReference fref = ins.Operand as FieldReference; if ( fref.DeclaringType.FullName == source.DeclaringType.FullName ) { ins.Operand = FindMatchingField( target.DeclaringType as TypeDefinition, fref ); } } else if ( ins.Operand is MethodReference ) { MethodReference mref = ins.Operand as MethodReference; if ( mref.DeclaringType.FullName == source.DeclaringType.FullName ) { ins.Operand = FindMatchingMethod( target.DeclaringType as TypeDefinition, mref ); } } }}#endregion
留意到它使用System.CodeDom与Cecil的方式：先利用System.CodeDom在另一个AppDomain生成了一个临时的assembly，然后利用Cecil找到那个assembly中要找的新的源方法，整个复制到目标方法里去，同时修正参数类型的不匹配。
这种方式的实现使得Reflexil只能整个方法替换，而没办法做真正的代码注入；不过跟Reflector一起用的话，这倒不是什么问题：反正Reflector能反编译出C#代码，那就把反编译出来的代码复制到新注入的代码中就是了。
但是……要是能有什么别的更自动的办法就好了。
3、使用C# 3.0的lambda expression，配合System.Linq.Expressions.Expression<TDelegate>来生成IL
C# 3.0中的expression tree相当的有趣。
当一个lambda expression被赋值给一个delegate类型，例如Action<T>或者Func<T, TResult>等，这个lambda expression会被编译器直接编译为
1) 当lambda expression没有使用闭包内的非局部引用也没有使用到this时，编译为一个私有静态方法；
2) 当lambda expression没有使用闭包内的非局部引用，但用到了this时，编译为一个私有成员方法；
3) 当lambda expression中引用到非局部变量，则编译为一个私有的内部类，将引用到的非局部变量提升为内部类的成员变量，将表达式的内容封装到内部类里的一个成员方法。
以前我在这里稍微讨论过相关的一些问题，可以参考一下。
不过，当一个lambda expression被赋值给一个System.Linq.Expressions.Expression<TDelegate>类型时，表达式的内容会被编译为一棵expression tree，而不会在编译时为其生成IL。直到真的调用那个Expression时才会进行到IL的编译。
用一段小程序来演示这个特性。
先把一个lambda expression（(x, y) => x << y）赋值给一个delegate，Func<int, int, int>：
using System;using System.Linq.Expressions;using System.Reflection;namespace TestLinqExpression{ class Program { static void Main(string[] args) { Func<int, int, int> shlFunc = (x, y) => x << y; MethodInfo method = shlFunc.Method; // gets a RuntimeMethodInfo instance Console.WriteLine(method); // Int32 <Main>b__0(Int32, Int32) Console.WriteLine(method.Invoke(null, new object[] { 3, 2 })); // 12 Console.WriteLine(shlFunc(3, 2)); // 12 } }}
编译后再利用Reflector反编译，会看到多了一个私有静态方法<Main>b__0，还有一个缓存这个delegate的一个私有成员域：
internal class Program{ // Methods private static void Main(string[] args) { Func<int, int, int> shlFunc = delegate (int x, int y) { return x << y; }; MethodInfo method = shlFunc.Method; Console.WriteLine(method); Console.WriteLine(method.Invoke(null, new object[] { 3, 2 })); Console.WriteLine(shlFunc(3, 2)); } private static int <Main>b__0(int x, int y) { return (x << y); } private static Func<int, int, int> CS$<>9__CachedAnonymousMethodDelegate1;}
留意到，上面的代码里同时使用了MethodBase.Invoke()（实际上是RuntimeMethodInfo.Invoke()）与直接用括号的方式来调用那个delegate，运行的结果都是一样的。
把lambda expression改为赋值给Expression<Func<int, int, int>>的话：
using System;using System.Linq.Expressions;using System.Reflection;namespace TestLinqExpression{ class Program { static void Main( string[ ] args ) { Expression<Func<int, int, int>> shlExp = ( x, y ) => x << y; Func<int, int, int> shlFunc = shlExp.Compile( ); MethodInfo method = shlFunc.Method; // gets a DynamicMethod.RTDynamicMethod instance Console.WriteLine( method ); // Int32 lambda_method(System.Runtime.CompilerServices.ExecutionScope, Int32, Int32) // Console.WriteLine( method.Invoke( null, new object[ ] { 3, 2 } ) ); // throws ArgumentException Console.WriteLine( shlFunc( 3, 2 ) ); // 12 } }}
则会发现那个表达式并没有被编译为IL，而是生成了一棵expression tree：
internal class Program{ // Methods private static void Main(string[] args) { ParameterExpression CS$0$0000; ParameterExpression CS$0$0001; Func<int, int, int> shlFunc = Expression.Lambda<Func<int, int, int>>( Expression.LeftShift( CS$0$0000 = Expression.Parameter(typeof(int), "x"), CS$0$0001 = Expression.Parameter(typeof(int), "y")), new ParameterExpression[] { CS$0$0000, CS$0$0001 }).Compile(); MethodInfo method = shlFunc.Method; Console.WriteLine(method); // Console.WriteLine(method.Invoke(null, new object[] { 3, 2 })); Console.WriteLine(shlFunc(3, 2)); }}
这棵“树”的表现方式不习惯的话可能会觉得有点怪。其实就是用括号来表示的树而已，没什么特别的。LINQ里的expression tree整个是静态类型的。这个问题以后写关于DLR的笔记的时候再讨论。
留意到这里得到的方法名跟前一个例子不一样了，expression tree通过Compile()方法被编译为IL，赋值给了一个Func<int, int, int>类型的delegate。不过却无法使用MethodBase.Invoke()（实际上是RTDynamicMethod.Invoke()）来进行调用。
在.NET Reference Source Code, System.Reflection.Emit.DynamicMethod.cs里有这样一段代码：
public override Object Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) { // We want the creator of the DynamicMethod to control who has access to the // DynamicMethod (just like we do for delegates). However, a user can get to // the corresponding RTDynamicMethod using Exception.TargetSite, StackFrame.GetMethod, etc. // If we allowed use of RTDynamicMethod, the creator of the DynamicMethod would // not be able to bound access to the DynamicMethod. Hence, we do not allow // direct use of RTDynamicMethod. throw new ArgumentException(Environment.GetResourceString("Argument_MustBeRuntimeMethodInfo"), "this");}
这段注释在这个文件里出现了好几次。反正就是不让直接用RTDynamicMethod来Invoke。直接用括号来对delegate调用倒是没问题。
说到底，我们只是要编译后的IL而已，能否直接Invoke没什么关系。
这个时候，可以通过DynamicMethod.GetMethodBody()来得到一个MethodBody，然后通过MethodBody.GetILAsByteArray()来获得IL所在的byte数组。
可是……拿到了byte数组，如何能让Cecil识别出来呢？这个就等到下次再写吧～
嗯，肯定会有人问说用这个lambda expression搭配LINQ的expression tree到底有什么好处。这个问题我一时也没想得特别清楚。我的几个出发点是：
1) lambda expression可以减少名字冲突的可能性。如果要注入的目标有好几个不同的地方，无论是外部编译还是用System.CodeDom，势必要为每个注入的位置都生成一次assembly，很麻烦，而且要想办法避免类型/方法名潜在的冲突的可能。
2) 生成时，最好能不生成完整的assembly，而是只生成方法。无论是外部编译还是System.CodeDom生成的都是完整的assembly，在这里算是overkill了。我们要的只是那个方法的内容而已。从一个delegate我们可以直接获取它的MethodInfo，进而得到MethodBody、byte[]等等，不用再花功夫跑到生成出来的assembly里去慢慢找我们要的方法……
3) lambda expression转换成expression tree之后，是被动态编译为IL的，但在编译时却能检查到语法错误。这要分开两方面看：
3a) lambda expression是C#语法的一部分，所以在编译时会被编译器检查。这样就不会像用System.CodeDom那样遇到缺乏IDE支持之类的问题了。
3b) expression tree既可以由lambda expression生成，也可以动态组装。相比之下，LINQ的expression tree比IL高级，组装起来也方便许多。假如做出一个什么InjectionCodeBuilder之类的，接受expression tree为参数的话，就既能照顾到编译时的lambda expression，也能照顾到运行时自行组装的expression tree。调用一个现成的Compile()方法就能编译为IL，何乐而不为呢。
P.S. 说到AOP，我不是不知道PostSharp……不过它在内部到底是怎么实现的我还没看清楚。这库的代码量也不小啊（晕乎
PostSharp Core里的code model和weaver大概是值得关注的点吧。
总之自己要是能做一个不同的AOP实现的话，总也是件有趣的事 ^ ^
页:
[1]