AssemblyBuilderAccess 枚举用于定义动态程序集的访问模式，控制其执行、保存与回收行为。Run 模式仅在内存中执行，适用于临时代码；Save 模式允许保存到磁盘但不可直接执行；RunAndSave 支持内存执行和磁盘保存，便于调试和复用；RunAndCollect 在 .NET Core+ 中引入，支持垃圾回收，避免内存泄漏。选择模式需权衡性能、持久性与资源管理，如频繁生成临时程序集应使用 RunAndCollect 防止内存泄漏，需持久化则选 RunAndSave。实际使用时需注意权限、I/O 开销及安全风险。示例代码展示了如何用 RunAndCollect 创建含 SayHello 方法的动态程序集，保存到磁盘并验证执行结果，体现了灵活性与实用性。
AssemblyBuilderAccess
枚举在 .NET 中，说白了，就是用来定义你动态创建的程序集（Assembly）能干些什么、它的“生命周期”和“持久性”是怎样的。它决定了这个程序集是只能在内存里跑跑就得了，还是能被保存到磁盘上，甚至还能在跑完之后被垃圾回收掉。简单来说，它控制了你构建的这个“代码包”能去哪儿，能活多久。
解决方案
要设置程序集的访问模式，你需要在创建
AssemblyBuilder
实例时，通过
AppDomain.DefineDynamicAssembly
（在旧版 .NET Framework 中）或者
AssemblyBuilder.DefineDynamicAssembly
（在 .NET Core/.NET 5+ 中）方法传入
AssemblyBuilderAccess
枚举值。这个枚举有几个关键成员，它们各自代表了不同的访问模式：
AssemblyBuilderAccess.Run
: 这是最常见的一种模式。它表示这个动态程序集只能在内存中执行。它不会被保存到磁盘，一旦应用程序域卸载或者进程结束，这个程序集也就跟着消失了。这种模式适合那些只需要临时生成代码并立即执行的场景，比如动态代理、表达式树编译等。
AssemblyBuilderAccess.Save
: 这种模式允许你将动态生成的程序集保存到磁盘上。它不能在内存中直接执行，你必须先保存它，然后再通过
Assembly.LoadFrom
或类似方法加载它才能运行。我个人觉得，这种模式在实际开发中用得比较少，因为它多了一步保存和加载的开销，通常我们更倾向于直接执行或同时执行和保存。
AssemblyBuilderAccess.RunAndSave
: 顾名思义，这个模式是
Run
和
Save
的结合。它允许你在内存中执行动态程序集，同时也可以将其保存到磁盘。这在调试动态生成代码时特别有用，因为你可以运行它，如果出错了，还能拿到磁盘上的文件用反编译工具看看究竟生成了什么玩意儿。
AssemblyBuilderAccess.RunAndCollect
: 这是 .NET Core/.NET 5+ 时代引入的一个非常重要的模式。它和
Run
类似，都允许在内存中执行。但关键区别在于，使用
RunAndCollect
创建的动态程序集是可以被垃圾回收器（GC）卸载的。这意味着，如果你创建了大量的短生命周期动态程序集，它们在不再被引用时可以被回收，从而避免内存泄漏。这对于那些需要频繁生成和销毁动态代码的场景简直是福音。
选择哪种模式，完全取决于你的具体需求和对程序集生命周期的管理策略。
为什么我们需要为动态程序集设置不同的访问模式？
说实话，这个问题问得挺到位的，因为一开始我可能也会觉得，不就是生成个代码嘛，干嘛搞这么多花样？但深入一点看，这些模式其实是针对不同应用场景和资源管理需求量身定制的。
你想想看，如果你只是想临时生成一段代码，比如一个简单的数学运算函数，执行完就拉倒，那把它保存到硬盘上是不是有点多余？不仅增加了I/O开销，还可能留下一些不需要的文件。这时候
Run
模式就非常合适，它轻量、高效，用完即焚，不留痕迹。
但反过来，如果你正在开发一个代码生成器，比如一个ORM工具，它需要根据数据库结构生成实体类和数据访问层代码，并且希望这些生成的代码可以被其他项目引用，或者在应用程序重启后仍然可用，那
RunAndSave
或者直接
Save
就显得不可或缺了。你可以把生成的程序集保存下来，然后像引用普通DLL一样去使用它。这在插件系统或者自定义业务逻辑编译场景下特别有用。
再者，就是现在大家越来越关注的内存管理问题。在 .NET Framework 时代，
Run
模式生成的动态程序集一旦加载，除非整个
AppDomain
卸载，否则它就一直呆在内存里，不会被垃圾回收。这对于那些需要频繁、大量生成临时代码的服务来说，简直是噩梦，很容易导致内存泄漏。
RunAndCollect
的出现，正是为了解决这个痛点。它允许你像管理普通对象一样管理动态程序集，当不再需要时，它有机会被GC回收，大大提升了长时间运行服务的稳定性。
所以，这些不同的访问模式，本质上是在性能、持久性、资源管理和调试便利性之间做权衡，让你能够更精细地控制动态代码的行为。
在实际开发中，选择AssemblyBuilderAccess模式有哪些常见的陷阱或注意事项？
选择
AssemblyBuilderAccess
模式，可不是随便拍脑袋就能决定的，里面藏着不少坑，或者说需要注意的地方。
一个很常见的误区，尤其是在从 .NET Framework 迁移到 .NET Core/.NET 5+ 的时候，就是对
Run
模式的理解。很多人习惯性地用
Run
来生成临时代码，但在 .NET Core/.NET 5+ 的长时间运行服务中，如果你频繁地用
Run
模式创建动态程序集，而又不卸载它们（因为
Run
模式本身不支持卸载），那么恭喜你，你的服务很可能会遭遇内存泄漏。这时候，你真正需要的是
RunAndCollect
。它能让那些短命的动态程序集在不再被引用时被GC回收，就像处理普通对象一样。我曾经就遇到过类似的问题，服务跑着跑着内存就上去了，最后才发现是动态代码生成没有正确回收。
另一个需要注意的点是
Save
模式。如果你选择了
Save
或
RunAndSave
，那么你的应用程序就需要有写入磁盘的权限。这在某些受限的环境下（比如IIS的特定配置、容器环境等）可能会成为问题。而且，频繁地进行磁盘I/O操作也会带来性能开销。此外，保存下来的DLL文件可能会被杀毒软件误报，或者在某些安全策略下被阻止执行，这些都是需要考虑的。
还有就是调试问题。当你的动态代码出现运行时错误时，如果是
Run
模式，你很难直接看到生成的IL代码或者进行断点调试。但如果是
Save
或
RunAndSave
模式，你至少可以拿到生成的DLL文件，用ILSpy或者dotPeek这样的反编译工具去查看里面的内容，这对于排查问题非常有帮助。说实话，有时候我宁愿多一点磁盘I/O，也要能把生成的DLL拿出来看看，不然排查起来简直是“盲人摸象”。
最后，别忘了安全。动态生成代码，尤其是在接受外部输入来构建代码逻辑时，存在代码注入的风险。无论你选择哪种访问模式，对输入进行严格的验证和沙箱化处理都是至关重要的。这和
AssemblyBuilderAccess
本身关系不大，但却是动态代码生成时一个不可忽视的背景问题。
如何在.NET中动态创建并使用一个可保存的程序集（RunAndSave）？
实际操作起来，创建一个可保存的动态程序集，并让它跑起来，其实没那么复杂，但确实需要一些步骤。这里我们以 .NET Core/.NET 5+ 为例，使用
RunAndSave
模式来创建一个简单的程序集，里面包含一个问候方法，然后将其保存到磁盘并执行。
首先，你需要引用
System.Reflection.Emit
命名空间。
using System;using System.Reflection;using System.Reflection.Emit;using System.IO;public class DynamicAssemblyExample{ public static void Main(string[] args) { // 1. 定义程序集名称和文件名 string assemblyName = "MyDynamicAssembly"; string moduleName = "MyDynamicModule.dll"; // 模块名通常就是文件名 string fileName = moduleName; // 保存到哪个文件 // 2. 创建一个 AssemblyBuilder，指定 RunAndSave 模式 // 注意：在 .NET Core/.NET 5+ 中，DefineDynamicAssembly 不再接受 AppDomain， // 而是直接通过 AssemblyBuilder.DefineDynamicAssembly 方法。 // 对于 .NET Framework，通常是 AppDomain.CurrentDomain.DefineDynamicAssembly(...) AssemblyBuilder assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly( new AssemblyName(assemblyName), AssemblyBuilderAccess.RunAndSave); // 关键在这里：RunAndSave // 3. 在程序集中定义一个模块 ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule(moduleName); // 4. 在模块中定义一个类型（例如，一个公共类） TypeBuilder typeBuilder = moduleBuilder.DefineType( "MyNamespace.MyDynamicClass", // 完整的类型名，包含命名空间 TypeAttributes.Public | TypeAttributes.Class); // 5. 在类型中定义一个方法 MethodBuilder methodBuilder = typeBuilder.DefineMethod( "SayHello", // 方法名 MethodAttributes.Public | MethodAttributes.Static, // 公开静态方法 typeof(string), // 返回类型 new Type[] { typeof(string) }); // 参数类型：一个字符串 // 6. 获取 ILGenerator，用于发出方法的中间语言指令 ILGenerator il = methodBuilder.GetILGenerator(); il.Emit(OpCodes.Ldarg_0); // 加载第一个参数（name） il.Emit(OpCodes.Ldstr, "Hello, "); // 加载字符串 "Hello, " il.Emit(OpCodes.Call, typeof(string).GetMethod("Concat", new Type[] { typeof(string), typeof(string) })); // 调用 String.Concat il.Emit(OpCodes.Ret); // 返回 // 7. 创建类型 Type dynamicType = typeBuilder.CreateType(); // 8. 保存程序集到磁盘 // 在 .NET Core/.NET 5+ 中，Save 方法需要一个 AssemblyLoadContext 的实例， // 并且通常是保存到当前目录或指定目录。 // 对于 .NET Framework，直接调用 assemblyBuilder.Save(fileName) 即可。 // 这里为了简单演示，我们直接在当前目录保存。 try { // 在 .NET Core/.NET 5+ 中，AssemblyBuilder.Save 是一个扩展方法， // 并且需要 System.Runtime.Loader.AssemblyLoadContext 配合。 // 但对于简单的保存，直接调用 AssemblyBuilder.Save(string assemblyFileName) 即可。 // 确保目录存在 string outputPath = Path.Combine(Directory.GetCurrentDirectory(), fileName); assemblyBuilder.Save(fileName); // 这样保存到当前执行目录 Console.WriteLine($"程序集已保存到: {outputPath}"); } catch (Exception ex) { Console.WriteLine($"保存程序集失败: {ex.Message}"); return; } // 9. 执行动态方法（直接从内存中的 AssemblyBuilder 获取） // 也可以从磁盘加载后再执行，但既然是 RunAndSave，直接在内存中执行更方便 MethodInfo sayHelloMethod = dynamicType.GetMethod("SayHello"); if (sayHelloMethod != null) { string result = (string)sayHelloMethod.Invoke(null, new object[] { "World from Dynamic Assembly!" }); Console.WriteLine($"动态方法执行结果: {result}"); } // 10. （可选）从磁盘加载并再次执行，验证保存是否成功 try { Assembly loadedAssembly = Assembly.LoadFrom(fileName); Type loadedDynamicType = loadedAssembly.GetType("MyNamespace.MyDynamicClass"); MethodInfo loadedSayHelloMethod = loadedDynamicType.GetMethod("SayHello"); if (loadedSayHelloMethod != null) { string loadedResult = (string)loadedSayHelloMethod.Invoke(null, new object[] { "Disk-loaded World!" }); Console.WriteLine($"从磁盘加载并执行结果: {loadedResult}"); } } catch (FileNotFoundException) { Console.WriteLine("无法从磁盘加载程序集，文件未找到。"); } catch (Exception ex) { Console.WriteLine($"从磁盘加载或执行失败: {ex.Message}"); } }}
这段代码首先创建了一个
AssemblyBuilder
并指定了
RunAndSave
模式。接着，它定义了一个模块、一个类型和一个静态方法
SayHello
。通过
ILGenerator
，我们为
SayHello
方法编写了简单的IL指令，使其能够拼接字符串并返回。关键一步是
assemblyBuilder.Save(fileName)
，它会将这个动态生成的程序集保存到当前执行目录。最后，我们既可以直接从内存中执行这个方法，也可以尝试从磁盘加载保存下来的DLL，并再次执行，以此来验证
RunAndSave
模式的有效性。
你会发现，用
RunAndSave
模式时，你既享受了立即执行的便利，又保留了调试和持久化的可能性。这在很多场景下，比如插件开发、动态代码分析等，都提供了极大的灵活性。
以上就是.NET的AssemblyBuilderAccess枚举如何设置程序集访问模式？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439533.html
微信扫一扫 
支付宝扫一扫 
