AssemblyBuilder能在运行时动态生成程序集，通过定义程序集、模块、类型、方法并编译为IL代码执行，适用于ORM、序列化、AOP、脚本引擎等高性能场景，尤其在需根据运行时信息生成优化代码时发挥关键作用；在.NET Core/.NET 5+中，虽面临源生成器的竞争，但结合AssemblyLoadContext实现可卸载程序集，仍为运行时代码生成的核心工具。
.NET的AssemblyBuilder类，说白了，就是让你能在程序运行时，像个魔法师一样凭空“变出”新的代码。它允许你动态地定义程序集（Assembly）、模块（Module）、类型（Type，比如类或结构体）、方法（Method）甚至是字段（Field）和属性（Property），然后把这些东西编译成可执行的中间语言（IL），最终加载到内存中执行。这不像我们平时写好代码再编译，而是程序跑着跑着，突然决定要生成一段新的代码来用。
解决方案
要用AssemblyBuilder动态创建程序集，核心流程可以概括为几个步骤，虽然听起来有点像在搭积木，但每一块都得严丝合缝：
定义动态程序集： 你需要一个AssemblyBuilder实例，它是所有动态代码的根。通常通过AssemblyBuilder.DefineDynamicAssembly方法来创建。这里你得指定程序集的名称，以及它将如何被访问（比如是只运行、还是可以保存到磁盘）。
using System;using System.Reflection;using System.Reflection.Emit;using System.Threading; // For Thread.Sleep if saving to disk// 定义程序集AssemblyName aName = new AssemblyName("MyDynamicAssembly");AssemblyBuilder ab = AssemblyBuilder.DefineDynamicAssembly(aName, AssemblyBuilderAccess.RunAndSave); // RunAndSave 表示既能运行也能保存
定义模块： 一个程序集可以包含一个或多个模块。对于大多数情况，一个模块就够了。通过AssemblyBuilder.DefineDynamicModule来创建。
// 定义模块ModuleBuilder mb = ab.DefineDynamicModule("MyDynamicAssembly", "MyDynamicAssembly.dll");
定义类型（类）： 接下来，你可以在模块中定义具体的类型，比如一个类。使用ModuleBuilder.DefineType，指定类的名称、特性（比如是public还是private）、基类等。
// 定义类型（类）TypeBuilder tb = mb.DefineType("MyDynamicClass", TypeAttributes.Public | TypeAttributes.Class);
定义方法： 在这个类中，你可以定义方法。这涉及到TypeBuilder.DefineMethod，指定方法名、返回类型、参数类型等。最关键的是，你需要获取一个ILGenerator来编写方法的中间语言（IL）代码。
// 定义方法MethodBuilder methodBuilder = tb.DefineMethod("SayHello", MethodAttributes.Public | MethodAttributes.Static, typeof(string), // 返回类型 new Type[] { typeof(string) }); // 参数类型ILGenerator ilGen = methodBuilder.GetILGenerator();ilGen.Emit(OpCodes.Ldarg_0); // 加载第一个参数（string name）ilGen.Emit(OpCodes.Ldstr, "Hello, "); // 加载字符串 "Hello, "ilGen.Emit(OpCodes.Call, typeof(string).GetMethod("Concat", new Type[] { typeof(string), typeof(string) })); // 调用string.ConcatilGen.Emit(OpCodes.Ret); // 返回
创建类型： 当你定义完所有成员后，需要调用TypeBuilder.CreateType()来“烘焙”这个类型。这会完成类型的创建过程，使其可以被实例化或调用。
// 创建类型Type dynamicType = tb.CreateType();
保存并使用（可选）： 如果你在DefineDynamicAssembly时使用了AssemblyBuilderAccess.Save或RunAndSave，你可以将生成的程序集保存到磁盘上。之后，你就可以通过反射来调用这个动态生成的类型和方法了。
// 保存程序集到磁盘ab.Save("MyDynamicAssembly.dll");// 使用动态生成的类型和方法MethodInfo sayHelloMethod = dynamicType.GetMethod("SayHello");if (sayHelloMethod != null){ string result = (string)sayHelloMethod.Invoke(null, new object[] { "World" }); // 静态方法，第一个参数为null Console.WriteLine(result); // 输出 "Hello, World"}
这个过程，坦白说，写起来有点繁琐，特别是IL代码的编写，简直是汇编语言的C#版，需要对IL指令集有相当的了解。但它的强大之处在于，你可以在运行时根据外部输入、配置甚至其他代码的行为，来定制和生成全新的执行逻辑。
动态程序集生成在哪些场景下能发挥最大价值？
当谈到AssemblyBuilder的用武之地，我首先想到的就是那些需要高度运行时灵活性和极致性能的场景。它不像我们日常开发那样，代码写死编译好就完事了，AssemblyBuilder更像是为“活”的代码而生。
一个很典型的例子是对象关系映射（ORM）框架，比如Entity Framework或NHibernate的底层实现。它们需要根据数据库表结构动态生成实体类，或者为查询表达式生成高效的SQL语句。如果每次都用反射来操作对象，性能开销会很大。而通过AssemblyBuilder，ORM可以生成一段直接操作数据库或实体属性的IL代码，执行效率几乎和手写代码一样快，因为它们绕过了反射的开销。这就像是ORM在运行时为你的特定数据模型量身定制了一套“高速公路”。
再比如序列化/反序列化器。像JSON.NET或protobuf-net这样的库，在处理复杂对象图时，如果每次都用反射遍历属性进行读写，效率会大打折扣。它们可以利用AssemblyBuilder，针对某个特定的类型，生成一段专门用于序列化或反序列化的IL代码。这段代码直接访问字段和属性，跳过了反射查找成员的步骤，性能自然飞升。我个人觉得，这种为了性能而“极限优化”的场景，AssemblyBuilder简直是不可替代的利器。
还有一些AOP（面向切面编程）框架或代理生成的场景。它们需要在运行时为现有类的方法注入额外的逻辑（比如日志、事务管理）。AssemblyBuilder可以动态生成一个继承自原类的新类，并重写其方法，在新方法中加入切面逻辑，然后调用原方法。这使得在不修改原始代码的情况下，实现了行为的增强。这就像是在不拆掉老房子的前提下，给它加盖了几层，或者改造了内部结构，让它拥有了新的功能。
最后，脚本引擎或表达式求值器也常常用到它。当用户输入一段脚本或一个数学表达式时，你可以将这段文本解析成抽象语法树，然后用AssemblyBuilder将这棵树转换成可执行的IL代码，而不是通过解释器逐行执行。这不仅能提高执行速度，还能更好地利用.NET运行时的优化能力。
总的来说，只要你需要在运行时根据不确定的输入生成高度优化、且性能敏感的代码，AssemblyBuilder就是你的“秘密武器”。它把编译器的部分能力带到了运行时，让你的程序变得更加灵活和强大。
使用AssemblyBuilder时可能遇到哪些常见的陷阱和挑战？
虽然AssemblyBuilder功能强大，但用起来可真不是件轻松的事。我个人觉得，它就像一把双刃剑，用好了事半功倍，用不好则可能把自己绕进去。
首先，最直接的挑战就是IL代码的编写和调试。编写IL代码就像是直接和CPU对话，你需要了解各种操作码（OpCodes），知道栈的推入弹出规则，以及如何处理分支、循环、异常等。这和我们平时写C#代码完全是两个世界。一个微小的IL错误就可能导致运行时崩溃，而且这种崩溃往往很难定位，因为你没有源代码，也没有直观的堆栈信息。调试动态生成的代码，如果不是保存到磁盘再用调试器附加，那简直是噩梦。我曾经为了一个小小的IL指令顺序错误，花了几个小时去排查，那种感觉就像是在漆黑的房间里找一根黑色的针。
其次是内存管理和程序集卸载的问题。在传统的.NET Framework中，一旦你用AssemblyBuilder加载了一个程序集到默认的AppDomain中，这个程序集就无法被卸载了。这意味着，如果你频繁地生成和加载新的程序集（比如在插件架构中），内存会不断增长，最终导致内存泄漏。虽然可以通过创建独立的AppDomain来隔离和卸载，但AppDomain本身的创建和销毁开销不小，而且在.NET Core/.NET 5+中，AppDomain的概念已经弱化甚至移除了。现在有了AssemblyLoadContext和可收集（Collectible）程序集，情况有所改善，但仍需谨慎处理。
再者，安全性也是一个需要考虑的方面。尤其是在.NET Framework中，代码访问安全性（CAS）可能会对动态生成的代码造成限制。如果你生成的代码尝试执行一些受限操作（比如访问文件系统或网络），可能会遇到权限问题。在.NET Core/.NET 5+中，CAS的概念虽然被移除了，但你仍然需要警惕注入恶意IL代码的风险，尤其是在处理外部输入时。
还有就是版本兼容性和依赖管理。动态生成的程序集可能依赖于你应用程序中已有的类型或第三方库。如果这些依赖的版本发生变化，或者你尝试在不同的上下文（比如插件）中加载动态程序集，可能会遇到类型加载失败或版本冲突的问题。这就像是在一个复杂的生态系统中，你引入了一个新的物种，需要确保它能和所有其他物种和谐共处。
最后，别忘了性能与复杂度的权衡。虽然动态生成代码可以带来极致的性能，但编写、测试和维护这些代码的复杂度也呈指数级增长。很多时候，通过常规的反射或者表达式树编译，也能达到不错的性能，而且开发成本要低得多。只有在性能瓶颈确实非常明显，且常规手段无法解决时，才值得考虑AssemblyBuilder。过度使用它，可能会让你的代码变得难以理解和维护。
AssemblyBuilder在现代.NET (Core/.NET 5+) 中扮演着怎样的角色？
在.NET Core和后续的.NET 5+时代，AssemblyBuilder的角色并没有消失，但其使用场景和一些底层机制确实发生了一些演变，这让它在某些方面变得更实用，而在另一些方面则需要新的思维模式。
最显著的变化是AppDomain的弱化与AssemblyLoadContext的崛起。在旧的.NET Framework中，AppDomain是隔离代码执行环境和实现程序集卸载的主要方式。但它本身比较重，且有诸多限制。在.NET Core/.NET 5+中，AppDomain几乎被废弃了，取而代之的是更轻量级、更灵活的AssemblyLoadContext。这意味着，如果你现在需要实现插件加载和卸载，或者隔离不同版本的依赖，你不再依赖AppDomain，而是通过自定义AssemblyLoadContext来实现。AssemblyBuilder生成的程序集可以被加载到特定的AssemblyLoadContext中，如果这个AssemblyLoadContext是可卸载的（IsCollectible），那么当它不再被引用时，整个上下文连同它加载的动态程序集都可以被垃圾回收。这极大地解决了传统框架下动态程序集无法卸载的痛点，让插件系统等场景变得更加可行。
其次，虽然AssemblyBuilder依然是运行时代码生成的核心，但源生成器（Source Generators）的出现，为一些场景提供了编译时代码生成的替代方案。源生成器是在编译阶段运行的，它们可以检查你的代码，并生成新的C#源文件，这些文件会和你的项目一起编译。对于那些在编译时就能确定生成逻辑的场景（比如为DTO生成INotifyPropertyChanged接口的实现，或者生成强类型配置类），源生成器是更推荐的选择，因为它避免了运行时的复杂性、性能开销和调试难题。你不需要处理IL指令，也不需要担心内存泄漏。所以，现在在考虑动态代码生成时，我们多了一个选择：是选择运行时生成（AssemblyBuilder），还是编译时生成（Source Generators）。
然而，对于那些运行时才能确定代码逻辑的场景，AssemblyBuilder依然是不可替代的。比如，你有一个规则引擎，用户可以动态定义复杂的业务规则，这些规则在运行时才被解析并需要高效执行；或者一个高性能的表达式求值器，它需要将用户输入的表达式编译成机器码。在这些场景下，编译时生成是无能为力的，AssemblyBuilder的价值依然闪耀。
此外，.NET Core/.NET 5+在性能方面本身就有很多提升，这使得AssemblyBuilder生成的代码能够更好地利用这些运行时优化。同时，随着语言和框架的不断演进，一些工具和库（如System.Linq.Expressions的编译）在底层可能也在使用AssemblyBuilder来生成高效代码，但它们将其复杂性封装起来，让开发者能更方便地利用其能力。
总而言之，AssemblyBuilder在现代.NET中依然是高级运行时代码生成的核心工具。它的使用模式随着AssemblyLoadContext的引入而变得更加灵活和安全，但同时也面临着源生成器在某些场景下的竞争。它依然是那些对性能和运行时灵活性有极致要求的应用的“幕后英雄”。
以上就是.NET的AssemblyBuilder类如何动态创建程序集？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1440754.html
微信扫一扫 
支付宝扫一扫 
