简介这是一份面向C#与WPF开发者的插件式DLL动态加载示例源码聚焦反射机制在桌面应用中的实际落地适合希望为现有WPF程序引入可扩展插件架构、提升软件灵活性的初中级开发者参考。压缩包共135个文件约477KB以cs源码、dll程序集、pdb调试符号、csproj工程文件及config配置为主另含xaml界面、sln解决方案与少量缓存文件完整呈现了多项目协作的工程结构。源码围绕插件目录扫描、Assembly.LoadFrom加载程序集、通过反射获取类型并借助Activator.CreateInstance实例化插件、以接口容器注册调用等关键环节展开同时涉及异常处理与AppDomain卸载思路可直接作为模板套用到自己的项目中。目前已有227人学习下载便于快速理解插件发现、加载与调用的完整链路。1. 从一份 WPF 插件式 DLL 动态加载源码说起它到底能解决什么做过 WPF 桌面项目的同学大概率都遇到过这种需求主程序已经交付到客户现场突然要加一个报表导出模块或者换一套采集协议重新编译整个解决方案再发版周期长、风险高。这份「基于 WPF 开发的插件式 DLL 动态加载源码」就是冲着这个痛点来的——它用反射把外部 DLL 在运行时挂进主程序主程序本身不动插件目录里丢一个 dll 进去重启就能用。压缩包里能看到Core.PluginMeterManager.csproj、PluginsTest.csproj、MainWindow.baml这些文件说明它不是一个空壳 Demo而是带界面、带插件管理器、带测试插件的完整可跑工程。适合两类人一是想给自己的 WPF 工具做扩展机制的开发者二是想搞明白Assembly.LoadFrom和反射到底怎么配合的新手。下面我按「先跑起来、再看原理、最后避坑」的顺序拆一遍。2. 把工程跑起来目录结构、引用关系与第一次加载2.1 三个 csproj 的分工与依赖方向拿到压缩包先别急着 F5先看清楚工程之间的引用方向这是插件架构能不能成立的前提。从文件名能判断出至少有三个工程Core.PluginMeterManager.csproj是插件管理核心PluginsTest.csproj是测试插件还有一个承载MainWindow.baml的主程序工程。正确的依赖方向是主程序引用 CoreCore 定义插件接口插件工程引用 Core 拿到接口定义但主程序绝不直接引用任何具体插件工程。这个方向一旦搞反比如主程序直接using PluginsTest那插件就退化成普通类库了动态加载的意义直接归零。我一般会在解决方案里单独建一个Contracts或Plugin.Abstractions类库只放接口和共享模型主程序和所有插件都引用它这样编译期大家认识同一个IPlugin类型运行期才谈得上用反射匹配。工程角色引用谁被谁引用主程序含 MainWindow宿主负责 UI 和加载入口Core无Core.PluginMeterManager定义接口、扫描目录、反射实例化无或仅基础库主程序、插件PluginsTest具体功能实现Core不被编译期引用2.2 插件接口的最小定义插件能被主程序「认出来」靠的是一个双方都认识的契约。这个接口要放在 Core 里方法签名尽量窄别把主程序的 UI 类型塞进去否则插件和宿主耦合死换界面就得重编译插件。// Core 工程中的插件契约所有插件必须实现 public interface IPlugin { // 插件显示名用于菜单或列表 string Name { get; } // 插件版本便于排查现场加载的是哪一版 string Version { get; } // 宿主调用入口参数用基础类型或共享模型别传 Window void Execute(object context); }逻辑说明Name和Version是给宿主做展示和日志用的现场排查时能一眼看出加载的是哪个 dll。Execute的context参数故意用object是为了让契约不依赖具体 UI 类型插件内部自己决定怎么用。参数说明如果你确定插件只处理某类数据可以把object换成 Core 里定义的共享模型类但千万别换成MainWindow这种宿主专属类型。2.3 扫描插件目录并反射实例化接口定好接下来是宿主启动时的加载逻辑。常见做法是把插件 dll 统一放在程序目录下的Plugins文件夹用Directory.GetFiles扫出来逐个Assembly.LoadFrom再遍历类型找实现了IPlugin的。public ListIPlugin LoadPlugins(string pluginDir) { var plugins new ListIPlugin(); if (!Directory.Exists(pluginDir)) return plugins; foreach (var dll in Directory.GetFiles(pluginDir, *.dll)) { try { // LoadFrom 会解析同目录依赖适合插件场景 var asm Assembly.LoadFrom(dll); foreach (var type in asm.GetTypes()) { // 跳过抽象类和接口本身只认可实例化的实现 if (type.IsAbstract || type.IsInterface) continue; if (!typeof(IPlugin).IsAssignableFrom(type)) continue; var plugin (IPlugin)Activator.CreateInstance(type); plugins.Add(plugin); } } catch (Exception ex) { // 单个插件加载失败不能拖垮整个宿主 Console.WriteLine($加载 {dll} 失败: {ex.Message}); } } return plugins; }逻辑说明外层 try-catch 是关键一个坏 dll 抛BadImageFormatException或ReflectionTypeLoadException时不能让整个主程序起不来。IsAssignableFrom判断的是「这个类型能不能当成 IPlugin 用」比字符串比对类型名可靠得多。参数说明pluginDir建议用AppDomain.CurrentDomain.BaseDirectory拼出来别用相对路径否则从不同工作目录启动会找不到插件。Activator.CreateInstance要求插件类有无参构造函数这点后面避坑章节会专门讲。3. 反射加载的核心机制LoadFrom、LoadFile 与类型匹配的边界3.1 LoadFrom 和 LoadFile 到底差在哪很多人写插件加载时随手选一个结果在现场遇到依赖找不到的玄学问题。这两个方法的差别不在「加载 dll」这个动作本身而在加载上下文Load Context和依赖解析策略。Assembly.LoadFrom(path)会把 dll 加载到默认的 LoadFrom 上下文并且当这个 dll 依赖同目录下的其他 dll 时运行时会尝试从同一目录去解析。插件场景下插件往往带一堆自己的依赖所以LoadFrom是更省心的选择。Assembly.LoadFile(path)则是完全隔离地加载不参与默认上下文的依赖解析除非你自己挂AssemblyResolve事件否则插件依赖的第三方库会直接报FileNotFoundException。我一般的原则是插件目录结构简单、依赖都放一起用LoadFrom需要同时加载同一个 dll 的多个版本做隔离才考虑LoadFile配合自定义解析。这份源码用的是反射方式LoadFrom是更贴合它「直接当模板用」定位的写法。3.2 GetTypes 抛异常与 ReflectionTypeLoadExceptionasm.GetTypes()这行是翻车高发区。只要插件 dll 里有一个类型引用了找不到的程序集GetTypes()就会整体抛ReflectionTypeLoadException而不是只跳过那一个类型。表现就是「明明插件类写对了就是加载不出来」。处理办法是捕获这个特定异常从它的Types属性里拿能加载的部分LoaderExceptions里看具体缺了什么。Type[] types; try { types asm.GetTypes(); } catch (ReflectionTypeLoadException ex) { // 能加载的类型照常返回加载不了的记录原因 types ex.Types.Where(t t ! null).ToArray(); foreach (var le in ex.LoaderExceptions) Console.WriteLine($类型加载异常: {le?.Message}); }逻辑说明ex.Types数组里失败的位置是 null用Where过滤掉即可这样至少不会因为一个坏类型丢掉整个插件的可用部分。参数说明LoaderExceptions是并行数组和Types一一对应排查时对着看就知道是哪个类型缺了哪个依赖。3.3 类型匹配为什么用 IsAssignableFrom 而不是名字比对有些教程图省事用type.Name MyPlugin或者type.FullName.Contains(Plugin)来找插件类。这种写法在插件改名、加命名空间、混淆之后就废了而且容易误伤。正确做法是基于接口做类型系统层面的判断。typeof(IPlugin).IsAssignableFrom(type)返回 true 的条件是type 实现了 IPlugin或者 type 继承自某个实现了 IPlugin 的基类。它走的是 CLR 的类型关系不受命名影响。配合type.IsAbstract和type.IsInterface过滤就能精准拿到可实例化的插件实现。这也是为什么接口必须放在双方都引用的 Core 工程里——只有编译期是同一个IPlugin类型运行期IsAssignableFrom才认。4. 插件注册、调用与卸载容器设计与 AppDomain 隔离4.1 用字典容器管理插件实例加载出来的插件实例得有地方存还要能按名字调用。最直接的是Dictionarystring, IPluginkey 用插件的Name属性。但要注意重名问题两个插件都叫「数据导出」时后加载的会覆盖前面的现场表现就是「少了一个插件」。private readonly Dictionarystring, IPlugin _plugins new(); public void Register(IPlugin plugin) { var key plugin.Name; // 重名时加后缀避免静默覆盖 if (_plugins.ContainsKey(key)) key ${key}_{Guid.NewGuid().ToString(N)[..6]}; _plugins[key] plugin; } public void Invoke(string name, object context) { if (_plugins.TryGetValue(name, out var plugin)) plugin.Execute(context); }逻辑说明重名加后缀是个低成本保险比直接抛异常友好至少插件都在。Invoke用TryGetValue而不是索引器避免 key 不存在时抛KeyNotFoundException把 UI 线程带崩。参数说明context由调用方决定传什么如果插件需要访问宿主服务建议传一个 Core 里定义的服务接口而不是直接传宿主对象。4.2 卸载插件为什么不能靠 Assembly 直接卸.NET Framework 里程序集一旦加载进 AppDomain 就没法单独卸载Assembly上没有Unload方法。想让插件能被卸掉唯一的路是把插件加载到一个独立的 AppDomain 里卸载时整个 AppDomain 一起Unload。代价是跨 AppDomain 通信要走 MarshalByRefObject 或序列化复杂度陡增。所以现实中的取舍是如果插件只是功能扩展、不需要热卸载就用默认 AppDomain 加载简单直接如果确实要支持「卸载插件不重启主程序」才上独立 AppDomain。这份源码定位是模板默认 AppDomain 方案更贴合它的复杂度。判断标准很简单——你的插件会不会频繁换版本且不能重启会才值得上 AppDomain。4.3 异常隔离别让一个插件拖垮宿主插件是外部代码质量不可控Execute里抛异常是常态。调用点必须包一层把插件异常和宿主逻辑隔开。public void SafeInvoke(string name, object context) { if (!_plugins.TryGetValue(name, out var plugin)) return; try { plugin.Execute(context); } catch (Exception ex) { // 记录插件名和堆栈方便定位是哪个插件的问题 Console.WriteLine($插件 {name} 执行异常: {ex}); } }逻辑说明异常在这里被吞掉并记录宿主 UI 不受影响用户最多看到这个插件没反应而不是整个程序崩溃。参数说明日志里一定要带插件名否则现场一堆插件根本不知道是谁抛的。生产环境建议把Console.WriteLine换成你的日志组件。5. 避坑与排查动态加载最容易翻车的五个点5.1 现象插件类明明实现了接口却加载不出来原因通常是插件工程引用的 Core 和主程序引用的 Core 不是同一份 dll导致运行期IPlugin是两个不同的类型IsAssignableFrom返回 false。常见于插件工程把 Core 以源码形式复制了一份或者 NuGet 版本不一致。解决Core 必须以项目引用或同一个 dll 的形式被双方共享绝不能各拷一份源码。排查时打印typeof(IPlugin).Assembly.Location和插件里接口的Assembly.Location两个路径不一致就是这个问题。5.2 现象Activator.CreateInstance 抛 MissingMethodException原因是插件类没有无参构造函数或者只定义了带参数的构造函数。Activator.CreateInstance(type)默认找的就是无参构造。解决插件类显式写一个无参构造函数需要依赖注入的话改成Activator.CreateInstance(type, args)传参或者约定插件通过Initialize方法接收依赖而不是构造函数。5.3 现象插件依赖的第三方 dll 报 FileNotFoundException原因是用了LoadFile或者插件依赖不在宿主探测路径里。默认 AppDomain 的探测路径是宿主目录插件目录不在其中。解决改用LoadFrom它会把插件所在目录纳入依赖解析或者在加载前挂AppDomain.CurrentDomain.AssemblyResolve事件手动从插件目录加载依赖。后者更可控但要注意别把宿主自己的依赖版本覆盖了。5.4 现象改了插件 dll 重新编译主程序加载的还是旧版本原因是 dll 被加载后文件被锁定或者你覆盖的是宿主目录里的旧副本而加载器读的是另一个路径。解决确认插件目录和加载路径一致编译插件前先关掉正在运行的主程序否则 dll 被占用根本覆盖不了。如果必须热更新就得走独立 AppDomain 卸载后再加载新版本。5.5 现象GetTypes 抛 ReflectionTypeLoadException插件整体失效原因是插件里某个类型引用了缺失的程序集GetTypes是整体操作一个坏类型全盘皆输。解决按 3.2 的写法捕获ReflectionTypeLoadException从ex.Types里取非 null 的部分继续处理同时把LoaderExceptions打到日志里定位缺失依赖。这样至少能保住插件里可用的部分。6. 进阶技巧把这份模板改造成可维护的插件框架跑通之后我一般会在这份源码基础上做三件事让它从「能用的 Demo」变成「敢上生产的框架」。第一件是给插件加元数据校验。光靠Name和Version不够实际项目里我会在接口上加一个ApiVersion宿主加载时比对主程序支持的版本区间不匹配的直接跳过并记日志。这样插件和宿主各自升级时不会因为接口变了而静默出错。public interface IPlugin { string Name { get; } string Version { get; } // 宿主支持的接口版本不匹配则拒绝加载 int ApiVersion { get; } void Execute(object context); } // 加载时校验 const int SupportedApi 1; if (plugin.ApiVersion ! SupportedApi) { Console.WriteLine($插件 {plugin.Name} 接口版本 {plugin.ApiVersion} 不兼容跳过); continue; }逻辑说明ApiVersion是宿主和插件之间的协议版本接口签名一变就递增宿主只加载匹配的插件。参数说明SupportedApi建议做成配置项而不是硬编码常量方便灰度。第二件是把插件目录和加载日志做成可观测的。现场排查最怕「插件没出来但不知道为啥」我会在加载完成后输出一张表扫描到几个 dll、成功几个、失败几个、失败原因分别是什么。这张表比任何断点都管用。排查项看什么常见结论扫描数量目录里 dll 个数为 0 说明路径错成功数量实例化成功的插件数少于扫描数说明有加载失败失败原因LoaderExceptions 内容定位缺失依赖或版本冲突接口版本ApiVersion 比对结果不匹配说明插件需重编第三件是给插件加载加一层「后悔药」——加载前先备份当前插件列表新加载失败时回滚到上一份可用列表保证宿主始终处于可用状态。这个习惯是我被现场「加载一半崩了」坑过之后养成的从那以后我每次改插件加载逻辑都强制走一遍「空目录、坏 dll、版本不匹配」三种异常场景再交付。希望这份拆解帮到你把这份模板真正用起来。本文还有配套的精品资源点击获取