c#中动态加载程序集可通过assembly.load、assembly.loadfrom、assembly.loadfile或assembly.load(byte[])实现；2. assembly.loadfrom会锁定文件且存在加载上下文冲突风险，适合简单场景；3. assembly.load通过全名加载，不锁定文件，适用于gac或应用程序路径下的程序集；4. assembly.load(byte[])从内存加载，避免文件锁定，适合热更新但需手动处理依赖；5. 动态加载后使用gettype获取类型，activator.createinstance创建实例，getmethod和invoke调用方法；6. .net framework中程序集无法单独卸载，需通过appdomain实现隔离与卸载；7. .net core/.net 5+推荐使用assemblyloadcontext，支持细粒度卸载、简化通信并可自定义依赖解析，是appdomain的现代化替代方案。
C#中，
Assembly类是处理程序集的核心。要动态加载程序集，我们通常会用到它提供的一些静态方法，比如
Assembly.Load、
Assembly.LoadFrom、
Assembly.LoadFile，甚至是从字节数组加载的
Assembly.Load(byte[])。这些方法允许你在运行时将外部的DLL或EXE文件加载到当前应用程序域中，然后就可以通过反射来探索其内部的类型、方法和属性，实现插件化、热更新等功能。
解决方案
动态加载程序集并使用其内部类型，一个典型的流程是这样的：
using System;
using System.IO;
using System.Reflection;
public class DynamicAssemblyLoader
{
public static void LoadAndExecute()
{
// 假设我们有一个名为 "MyPlugin.dll" 的程序集，其中包含一个名为 "MyPlugin.MyClass" 的类
// 这个类有一个公共方法叫做 "Execute"
string assemblyPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "MyPlugin.dll");
if (!File.Exists(assemblyPath))
{
Console.WriteLine($"错误：未找到程序集文件：{assemblyPath}");
// 为了演示，这里可以模拟创建一个简单的DLL
// 实际应用中，你需要确保MyPlugin.dll存在
Console.WriteLine("请确保有一个名为 'MyPlugin.dll' 的文件在应用程序目录下。");
Console.WriteLine("示例：一个简单的MyPlugin.dll可以包含以下代码：");
Console.WriteLine("namespace MyPlugin { public class MyClass { public string Execute(string input) { return $\"Plugin executed with: {input}\"; } } }");
return;
}
try
{
// 方式一：使用 Assembly.LoadFrom - 适用于从指定路径加载，会锁定文件
// Assembly pluginAssembly = Assembly.LoadFrom(assemblyPath);
// 方式二：使用 Assembly.Load - 如果程序集在GAC或应用程序基路径下，或者你知道它的全名
// 这里为了演示，我们先加载到内存，避免文件锁定问题，但需要先读取文件到字节数组
byte[] assemblyBytes = File.ReadAllBytes(assemblyPath);
Assembly pluginAssembly = Assembly.Load(assemblyBytes);
Console.WriteLine($"成功加载程序集：{pluginAssembly.FullName}");
// 获取程序集中的特定类型
// 假设我们知道要加载的类型是 "MyPlugin.MyClass"
Type myClassType = pluginAssembly.GetType("MyPlugin.MyClass");
if (myClassType != null)
{
Console.WriteLine($"找到类型：{myClassType.FullName}");
// 创建该类型的实例
object instance = Activator.CreateInstance(myClassType);
// 获取并调用实例上的方法
MethodInfo executeMethod = myClassType.GetMethod("Execute");
if (executeMethod != null)
{
// 假设Execute方法接受一个字符串参数并返回一个字符串
object result = executeMethod.Invoke(instance, new object[] { "Hello from main app!" });
Console.WriteLine($"方法调用结果：{result}");
}
else
{
Console.WriteLine("未找到 'Execute' 方法。");
}
}
else
{
Console.WriteLine("未找到 'MyPlugin.MyClass' 类型。");
}
}
catch (FileNotFoundException ex)
{
Console.WriteLine($"文件未找到错误：{ex.Message}");
}
catch (BadImageFormatException ex)
{
Console.WriteLine($"程序集格式错误（可能不是有效的.NET程序集）：{ex.Message}");
}
catch (Exception ex)
{
Console.WriteLine($"加载或执行程序集时发生错误：{ex.Message}");
Console.WriteLine(ex.StackTrace);
}
}
// 主函数，用于演示
public static void Main(string[] args)
{
Console.WriteLine("开始动态加载程序集演示...");
LoadAndExecute();
Console.WriteLine("动态加载程序集演示结束。");
Console.ReadKey(); // 等待用户按键，以便查看输出
}
}
/*
为了运行上述代码，你需要创建一个名为 MyPlugin.dll 的项目：
1. 创建一个新的 C# 类库项目，命名为 MyPlugin。
2. 将以下代码复制到 MyPlugin 项目的 Class1.cs (或任何你喜欢的名称) 中：
namespace MyPlugin
{
public class MyClass
{
public string Execute(string input)
{
return $"Plugin executed with: {input} (from MyPlugin.dll)";
}
}
}
3. 编译 MyPlugin 项目，然后将生成的 MyPlugin.dll 复制到你的主应用程序（DynamicAssemblyLoader 所在项目）的 Debug/Release 目录下。
*/C#动态加载程序集：为何需要？
在我看来，动态加载程序集简直是现代软件设计中实现灵活性和扩展性的杀手锏。你想想看，一个软件产品，如果所有功能都写死在主程序里，那每次更新、增加新功能或者修复bug，都得重新编译、发布整个应用，这对于用户体验和开发效率来说，都是个灾难。
动态加载就完全不同了。我个人觉得它最核心的价值在于：
-
插件化架构：这是最常见的应用场景。你可以把不同的功能模块做成独立的DLL，主程序只提供一个框架，运行时按需加载这些插件。比如，一个图片处理软件，各种滤镜效果可以做成插件；一个IDE，各种语言支持、调试器可以做成插件。这样，用户可以根据自己的需求安装或卸载特定插件，开发者也能独立更新某个插件，而无需触及主程序。
热更新与版本管理：在某些场景下，你可能需要在不重启应用的情况下更新部分功能。比如，一个后台服务，你可以动态加载新版本的业务逻辑DLL，然后旧的DLL（如果不再被引用）可以被新的替换掉，这对于需要高可用性的系统非常关键。当然，这里面涉及的复杂性也不少，比如如何优雅地切换、如何处理旧版本的引用等等。
降低启动开销：如果你的应用功能非常多，但用户通常只用到其中一小部分，那么在启动时加载所有DLL会造成不必要的内存占用和启动时间。通过动态加载，你可以只在用户真正需要某个功能时才加载对应的程序集，从而优化应用的启动性能和资源消耗。
A/B测试与配置化：你可以动态加载不同版本的业务逻辑DLL，来实现A/B测试，或者根据用户的配置动态启用不同的功能模块。
隔离性：虽然不是所有动态加载都能实现完全隔离，但配合
AppDomain或 .NET Core/.NET 5+ 中的
AssemblyLoadContext，你可以将不同的程序集加载到不同的上下文，避免版本冲突（DLL Hell）和资源泄露。
总的来说，动态加载给了我们更多的自由度，让软件变得更“活”，更能适应不断变化的需求。
Assembly.LoadFrom与Assembly.Load：如何选择及常见陷阱？
说实话，刚开始用的时候，这些
Load方法把我搞得头大，它们看起来很像，但行为上却有微妙而重要的区别。理解它们各自的特点和潜在的坑，是避免踩雷的关键。
Assembly.LoadFrom(string assemblyFile)
：
-
文件锁定：
LoadFrom加载的程序集会锁定其源文件。这意味着在程序集被卸载（通常是整个应用程序域被卸载）之前，你无法删除、移动或覆盖这个DLL文件。这对于热更新场景是个大问题。 加载上下文：它会将程序集加载到一个新的“加载上下文”（LoadFrom context）中。如果同一个程序集被多次
LoadFrom加载（即使路径不同，但程序集标识相同），或者同一个程序集同时被
LoadFrom和
Load加载，就可能出现类型冲突的问题。简单来说，运行时可能会认为两个相同的类型是不同的类型，导致
InvalidCastException。 依赖解析：虽然它会尝试解析依赖，但在复杂场景下，如果依赖DLL不在主应用程序的探测路径中，或者版本冲突，就可能出现
FileNotFoundException或
BadImageFormatException。
Assembly.Load(string assemblyName)
：
-
路径无关：你不能直接指定文件路径。如果程序集不在GAC或应用程序的探测路径中，它就找不到。
全名匹配：需要精确的程序集全名，包括版本号、文化信息和公钥令牌（如果已签名）。这在开发阶段可能有点麻烦。
Assembly.Load(byte[] rawAssembly)
：
-
依赖处理：如果加载的程序集有外部依赖，这些依赖也需要以某种方式被解析。通常你需要订阅
AppDomain.CurrentDomain.AssemblyResolve事件，手动提供依赖程序集的字节数组或路径。这增加了复杂性。 调试困难：从字节数组加载的程序集，调试起来会比从文件加载的更困难，因为没有对应的PDB文件。
Assembly.LoadFile(string path)
：
-
无法解析依赖：由于它不加载依赖，如果你的程序集内部有引用，那么在尝试使用这些引用时会失败。这使得它在大多数实际应用场景中不太实用，除非你确定程序集是完全独立的。
文件锁定：和
LoadFrom一样，也会锁定文件。
如何选择？
最推荐（尤其是在 .NET Framework 中需要卸载）：如果你需要热更新或插件卸载，那么通常的模式是byte[]+
AppDomain。将程序集读取到
byte[]，然后在新的
AppDomain中加载并使用它。这样，当需要更新时，卸载整个
AppDomain就可以释放文件锁。 .NET Core/.NET 5+ 的现代化选择：
AssemblyLoadContext是一个更现代、更强大的替代
AppDomain的机制，它允许你创建独立的加载上下文并按需卸载。在这种情况下，通常也会结合
byte[]或
LoadFrom。 简单场景：如果你的DLL不需要热更新，且不会造成文件锁定问题，
LoadFrom是最简单的。但要小心加载上下文的问题。 GAC 或已知路径：如果程序集已经注册到GAC，或者你确定它在应用程序的探测路径中，
Load(string assemblyName)是一个干净的选择。
在我看来，如果你刚接触动态加载，并且遇到了
InvalidCastException或文件锁定问题，那多半是
LoadFrom的锅。理解这些加载上下文的细微差别，真的能帮你省掉很多头发。
动态加载程序集后，如何利用反射进行类型操作？
这部分才是真正把动态能力变现的关键。程序集加载进来后，它只是内存中的一堆二进制数据，你需要通过反射（Reflection）这把“钥匙”去打开它，看看里面有什么，然后才能实例化对象、调用方法。
获取类型（GetType
）：
加载
Assembly对象后，第一步通常是找到你需要的类型。你可以通过
Assembly.GetType(string typeName)方法，传入类型的完整名称（包括命名空间）来获取
Type对象。
Type myPluginType = loadedAssembly.GetType("MyPlugin.MyClass");
if (myPluginType == null)
{
Console.WriteLine("类型未找到！");
return;
}如果不知道完整名称，或者需要遍历程序集中的所有类型，可以使用
Assembly.GetTypes()方法，它会返回一个
Type[]数组。
创建实例（Activator.CreateInstance
或 Assembly.CreateInstance
）：
拿到
Type对象后，你就可以创建这个类型的一个实例了。
Activator.CreateInstance(Type type)：这是最通用的方法，可以创建任何公共无参构造函数的类型实例。
object instance = Activator.CreateInstance(myPluginType);
// 如果构造函数有参数，可以使用 Activator.CreateInstance(Type type, params object[] args)
// object instance = Activator.CreateInstance(myPluginType, new object[] { "some_param" });
Assembly.CreateInstance(string typeName)：这是
Assembly类提供的一个便捷方法，它内部其实也是调用了
Activator.CreateInstance。
object instance = loadedAssembly.CreateInstance("MyPlugin.MyClass");创建出来的实例是
object类型，你需要将其转换为实际的类型（如果知道的话）或者通过接口进行操作。
调用方法（MethodInfo.Invoke
）：
有了实例，接下来就是调用它的方法了。
Type.GetMethod(string methodName)来获取
MethodInfo对象。如果方法有重载，你可能需要使用
GetMethod(string methodName, Type[] parameterTypes)来指定参数类型以区分。
MethodInfo executeMethod = myPluginType.GetMethod("Execute");
if (executeMethod == null)
{
Console.WriteLine("方法未找到！");
return;
}
调用方法：使用 MethodInfo.Invoke(object obj, object[] parameters)。第一个参数是方法所属的实例（如果是静态方法则为
null），第二个参数是方法的参数数组。
object result = executeMethod.Invoke(instance, new object[] { "Data from host app" });
Console.WriteLine($"方法返回：{result}");
关于反射的性能和注意事项：
反射虽然强大，但它不是没有代价的。
性能开销：反射操作比直接调用方法要慢得多。因为它需要在运行时查找类型、方法等信息。如果你的应用程序需要频繁地调用通过反射加载的方法，性能可能会成为瓶颈。 类型安全：反射是运行时操作，编译时无法检查类型错误。这意味着你可能会在运行时遇到TargetParameterCountException、
ArgumentException等错误，因为你传递了错误的参数数量或类型。 代码可读性：大量使用反射的代码往往不如直接调用的代码清晰易读。
所以，我的建议是，在确实需要灵活性和动态性的场景下使用反射。对于那些性能敏感或类型明确的固定功能，还是老老实实地直接引用和调用吧。有时候，为了那一点点的“酷炫”，付出的调试和维护成本可不低。
C#动态加载的程序集可以卸载吗？AppDomain的替代方案
说起卸载，这简直是动态加载里最让人头疼的问题之一。在 .NET Framework 中，一个程序集一旦被加载到应用程序域（
AppDomain）中，它就无法单独被卸载。这就像你把一本书放进了书架，除非你把整个书架都搬走，否则你没法只把那本书拿出来扔掉。
这意味着，如果你用
Assembly.LoadFrom或
Assembly.Load(byte[])把一个插件DLL加载进
AppDomain.CurrentDomain（也就是你的主应用程序域），那么这个DLL就会一直留在内存里，直到你的应用程序进程结束。这对于需要热更新、频繁加载/卸载插件的场景来说，是个巨大的障碍，因为旧版本的DLL文件会被锁定，无法更新。
解决方案（.NET Framework）：AppDomain
在 .NET Framework 中，唯一的解决方案就是利用
AppDomain。
AppDomain是一个独立的应用程序域，你可以把它看作是一个轻量级的进程。你可以：
-
创建一个新的
AppDomain：
AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; // 设置基路径
// 可以设置私有探测路径等
AppDomain pluginDomain = AppDomain.CreateDomain("PluginDomain", null, setup);
在新的 AppDomain中加载程序集： 你需要一个“代理”对象，这个代理对象要继承自
MarshalByRefObject，这样它才能在不同的
AppDomain之间进行通信。
// 假设你的代理类在主程序中，负责加载插件
// public class PluginLoader : MarshalByRefObject { public void LoadPlugin(string assemblyPath) { /* ... */ } }
PluginLoader loader = (PluginLoader)pluginDomain.CreateInstanceAndUnwrap(
Assembly.GetExecutingAssembly().FullName, // 当前程序集的全名
typeof(PluginLoader).FullName // 代理类的全名
);
loader.LoadPlugin("MyPlugin.dll"); // 在新的AppDomain中加载插件在
PluginLoader的
LoadPlugin方法中，你就可以使用
Assembly.LoadFrom或
Assembly.Load(byte[])来加载插件了，因为它运行在
pluginDomain中。 卸载
AppDomain： 当你想卸载插件时，直接卸载整个
AppDomain就可以了。
AppDomain.Unload(pluginDomain);
Console.WriteLine("插件AppDomain已卸载，程序集已释放。");卸载
AppDomain会释放其中加载的所有程序集和资源，从而解除对DLL文件的锁定。
AppDomain
的局限性：
AppDomain通信需要处理序列化、代理对象等，增加了代码的复杂性。 性能开销：创建和销载
AppDomain有一定的性能开销。 隔离不彻底：虽然隔离了程序集，但某些全局资源（如静态变量、COM对象）可能仍然是共享的。
.NET Core/.NET 5+ 的替代方案：AssemblyLoadContext
幸运的是，在 .NET Core/.NET 5+ 中，微软引入了
AssemblyLoadContext，这是一个更现代、更轻量级的程序集加载和隔离机制，它旨在解决
AppDomain的诸多痛点，特别是程序集卸载的问题。 核心思想：你可以创建自定义的
AssemblyLoadContext实例，并将程序集加载到这个上下文中。当这个上下文被销毁时，其中加载的程序集也会被卸载，从而释放文件锁。 优势： 细粒度卸载：你可以卸载单个
AssemblyLoadContext，而不是整个
AppDomain。 简化通信：不再需要
MarshalByRefObject，可以直接传递对象（只要类型在两个上下文都可见）。 更灵活的依赖解析：你可以重写
Load方法来控制依赖的加载逻辑。
示例（AssemblyLoadContext
概念性代码）：
// 这是一个概念性的示例，实际使用需要更严谨的实现 using System.Runtime
