在 C# 开发中，插件化架构的核心目标是让主程序在不重新编译发布的情况下，动态吸纳新功能模块。实现这一能力的关键技术之一，便是利用 Assembly.Load 系列方法在运行时加载外部程序集，并通过反射机制创建实例、调用方法。
一、插件化架构的基本设计思路
插件化架构通常包含三个角色：主程序宿主、插件接口契约、具体插件实现。主程序只依赖接口契约程序集，不依赖任何插件实现；插件实现则引用同一份接口契约并独立完成功能。这样，新增插件只需提供一个实现了约定接口的 DLL，宿主在启动时或运行中扫描目录并加载即可。
如果直接在项目中添加 DLL 引用，那么每次增加功能都要重新编译主程序，失去了“插拔”的意义。而通过 Assembly.Load 从指定路径加载，宿主和插件在编译期解耦，部署时只需拷贝文件。需要注意的是，接口契约程序集的版本应保持稳定，否则会引发 MissingMethodException 等运行时错误。
1.1 定义统一的插件接口
我们先创建一个独立的类库项目 PluginContract，其中定义所有插件都要实现的接口。这个程序集将被主程序和插件共同引用，但不包含任何业务逻辑。
例如，定义一个执行处理的接口，任何插件都实现 IPlugin 并暴露名称与执行方法。通过接口，宿主无需关心插件内部怎么写，只管调用统一方法。这种设计也方便后期做权限校验、生命周期管理。
// PluginContract 类库中的接口定义
public interface IPlugin
{
string Name { get; }
void Execute();
}
1.2 插件实现示例
插件项目引用 PluginContract，然后写一个具体类。编译后得到的 DLL 放到主程序约定的插件目录中即可，不需要主程序重新生成。
下面代码展示了一个简单插件，它在执行时输出自身名称。实际业务中，这里可以替换成数据导入、报表生成或第三方服务对接等逻辑。
// PluginA 项目，引用 PluginContract
using System;
public class PluginA : IPlugin
{
public string Name => "PluginA";
public void Execute()
{
Console.WriteLine("插件 A 开始执行任务");
}
}
二、使用 Assembly.Load 加载程序集
Assembly.Load 有多种重载，最常用于插件场景的是 Assembly.LoadFrom 和 Assembly.LoadFile。前者会一并加载其依赖项并记录加载上下文，后者仅加载指定文件本身。一般推荐使用 LoadFrom，因为它能自动解析同目录下的依赖 DLL。
在 .NET Core 及后续版本中，还引入了 AssemblyLoadContext，可以实现插件隔离与卸载，避免传统 AppDomain 的复杂模型。不过对于简单场景，直接使用 Assembly.LoadFrom 已足够清晰。
2.1 扫描插件目录并加载
主程序启动时，遍历插件文件夹中所有 .dll 文件，逐个调用 Assembly.LoadFrom，再从程序集中查找实现了 IPlugin 的类型。
以下代码演示了基本加载流程：先取目录文件，再加载程序集，最后用 GetTypes 配合接口判断来筛选插件类。这里要注意捕获异常，因为某些 DLL 可能不是插件或存在损坏。
using System;
using System.IO;
using System.Reflection;
using PluginContract;
class PluginLoader
{
public static void LoadAll(string pluginDir)
{
if (!Directory.Exists(pluginDir))
return;
foreach (var dll in Directory.GetFiles(pluginDir, "*.dll"))
{
try
{
Assembly asm = Assembly.LoadFrom(dll);
foreach (var type in asm.GetTypes())
{
if (typeof(IPlugin).IsAssignableFrom(type) && !type.IsAbstract)
{
IPlugin plugin = (IPlugin)Activator.CreateInstance(type);
plugin.Execute();
}
}
}
catch (Exception ex)
{
Console.WriteLine("加载失败: " + dll + " 原因:" + ex.Message);
}
}
}
}
2.2 反射创建实例与调用
上面用 Activator.CreateInstance 创建了插件对象。若插件构造函数需要参数，可改用 CreateInstance(Type, object[]) 重载传入。创建后，即可像普通对象一样调用接口方法。
为了避免重复加载同一程序集，可在加载前用 AppDomain.CurrentDomain.GetAssemblies() 检查是否已存在。另外，若插件之间不能互相影响，应考虑使用独立 AssemblyLoadContext 隔离，而不是全部塞进默认上下文。
// 检查是否已加载某程序集
var loaded = AppDomain.CurrentDomain.GetAssemblies()
.Any(a => a.Location.Equals(dll, StringComparison.OrdinalIgnoreCase));
if (!loaded)
{
Assembly asm = Assembly.LoadFrom(dll);
}
三、依赖冲突与卸载问题
当多个插件引用了不同版本的同一 NuGet 包，默认加载上下文会产生冲突，表现为运行时找不到方法或类型。传统解决方式是把插件放进不同子目录并配合 <assemblyBinding> 配置，但更现代的做法是用 AssemblyLoadContext 做隔离。
另一个痛点是 .NET Framework 中已加载的 Assembly 无法卸载，除非借助 AppDomain。而 .NET Core 的 AssemblyLoadContext 支持 Unload，前提是相关类型没有被默认上下文引用。因此设计插件 API 时，应尽量避免把插件类型暴露到宿主全局静态变量中。
3.1 使用 AssemblyLoadContext 隔离
下面示例创建了一个自定义上下文加载插件，使插件依赖与主程序分开解析，降低冲突概率。
注意 AssemblyLoadContext 的 Load 方法可重写以定制依赖查找逻辑。执行完若不再需要，调用 Unload 释放（需确保无引用残留）。
using System;
using System.Reflection;
using System.IO;
class PluginContext : AssemblyLoadContext
{
private string _path;
public PluginContext(string path) : base(isCollectible: true)
{
_path = path;
}
protected override Assembly Load(AssemblyName name)
{
var file = Path.Combine(_path, name.Name + ".dll");
if (File.Exists(file))
return LoadFromAssemblyPath(file);
return null;
}
}
3.2 插件化架构的优缺点分析
优点方面，插件化让系统扩展性极强，业务团队可并行开发互不干扰，主程序升级频率降低。同时故障隔离更好，单个插件异常可被捕获而不拖垮整体。
缺点则是调试复杂，反射调用缺少编译期检查，版本契约一旦破坏就难排查。此外加载与卸载若设计不当，容易造成内存泄漏。因此中小项目应权衡是否真需要动态插件，还是用模块化项目引用更省事。
| 方案 | 耦合度 | 卸载支持 | 适用场景 |
|---|---|---|---|
| 项目引用 | 高 | 随进程 | 功能固定内部系统 |
| Assembly.LoadFrom | 低 | 不支持 | 简单插件工具 |
| AssemblyLoadContext | 低 | 支持 | 长运行可扩展服务 |
四、总结与实践建议
采用 Assembly.Load 相关方法实现 C# 插件化架构，核心在于：稳定接口契约、目录化发现、反射实例化、上下文隔离。开发时先把接口抽干净，再为插件建立独立项目模板，能大幅减少后期摩擦。
若你正准备重构一个臃肿的单块程序，不妨从边缘功能做起，把它们改成插件逐步抽离。配合日志与异常捕获，插件化带来的维护收益会随着系统成长越来越明显。
C#插件化架构Assembly_Load修改时间：2026-08-07 05:45:38