简介这是一份面向C#与WPF开发者的插件式DLL动态加载示例源码适合希望为桌面应用引入可扩展插件架构的中级开发者参考。资源以反射为核心演示了从插件目录查找DLL、通过Assembly.LoadFrom加载程序集、利用GetTypes与IsAssignableFrom筛选实现插件接口的类型、再以Activator.CreateInstance实例化并注册到主程序容器的完整链路同时涉及异常处理与AppDomain卸载等稳定性考量。压缩包共135个文件约477KB以cs源码、dll程序集、pdb调试符号、csproj工程文件及xaml界面文件为主另含config配置与缓存文件结构接近可直接运行的Visual Studio解决方案。目前已有227人学习下载。读者可将其作为模板快速理解插件发现、加载、调用与卸载的实现方式并迁移到自己的WPF项目中提升软件可扩展性。1. 插件式 DLL 动态加载为什么你的 WPF 主程序不该在编译期认识任何插件做过 WPF 桌面交付的人迟早会撞上同一个需求主程序上线之后客户还在不断要新功能而每次加功能都得重新编译、重新打包、重新走一遍安装流程。插件式 DLL 动态加载就是冲着这个痛点来的——主程序只负责壳、菜单、容器和通信契约具体业务逻辑全部塞进独立 DLL运行时用反射把程序集读进来、找到实现了约定接口的类、实例化、挂到界面上。标题里这套「基于 WPF 开发的插件式 DLL 动态加载源码使用反射方式实现」本质就是一份可以直接当模板用的最小骨架一个 WPF 宿主一个插件契约接口一个基于反射的加载器外加一个示例插件。它适合谁适合已经会写 WPF 窗口、但对「程序集隔离」「接口契约」「加载上下文」这些词还停留在听说阶段的 .NET 开发者也适合手上有个老 WPF 项目、想在不推翻现有代码的前提下把模块拆出去的人。反射在这里不是炫技而是唯一能在编译期互不相识的两个程序集之间建立调用关系的常规手段。读完你应该能自己搭出一套能跑、能扩展、能排错的插件骨架而不是只会复制一个 Demo。2. 反射加载的底层账程序集、契约与实例化到底发生了什么2.1 从 DLL 文件到可用对象中间隔了四步很多人以为「反射加载」就是一句Assembly.LoadFrom其实从磁盘上的一个.dll到一个能调用的对象中间有四个明确阶段每一步都可能翻车。第一步是定位程序集。你手上只有路径字符串Assembly.LoadFrom(path)会把这个文件读进当前应用程序域返回一个Assembly对象。注意这里有个容易被忽略的点LoadFrom会先看当前域里有没有同名程序集有就直接复用不会重新加载。这在插件热更新场景里是致命的——你替换了 DLL 文件结果加载的还是内存里那份旧的。第二步是扫描类型。拿到Assembly之后用assembly.GetTypes()或GetExportedTypes()枚举里面所有类型。前者包含非公开类型后者只返回 public 的。插件契约接口一定是 public所以用GetExportedTypes()更干净也能少踩一些访问权限的坑。第三步是契约匹配。判断某个类型是不是插件靠的是typeof(IPlugin).IsAssignableFrom(type)而不是字符串比类名。这是整个方案能成立的关键宿主和插件共享同一个契约接口所在的程序集双方都引用它于是类型身份一致IsAssignableFrom才返回 true。如果你把契约接口在宿主和插件里各定义一份哪怕代码一模一样CLR 也认为是两个不同类型匹配必然失败。第四步是实例化。Activator.CreateInstance(type)走的是无参构造要求插件类必须有一个公开无参构造函数。如果你的插件需要注入依赖就得换成带参数的CreateInstance或者干脆用工厂方法。// PluginLoader.cs —— 反射加载的核心四步 public IReadOnlyListIPlugin LoadPlugins(string pluginDirectory) { var plugins new ListIPlugin(); // 第一步定位所有 dll 文件 var dllFiles Directory.GetFiles(pluginDirectory, *.dll, SearchOption.TopDirectoryOnly); foreach (var dllPath in dllFiles) { // 第二步加载程序集LoadFrom 会缓存热更新需换 LoadFile 或独立 ALC var assembly Assembly.LoadFrom(dllPath); // 第三步扫描并匹配契约接口 var pluginTypes assembly.GetExportedTypes() .Where(t typeof(IPlugin).IsAssignableFrom(t) // 实现了契约 !t.IsAbstract // 排除抽象基类 !t.IsInterface); // 排除接口本身 foreach (var type in pluginTypes) { // 第四步实例化并收集 if (Activator.CreateInstance(type) is IPlugin plugin) { plugins.Add(plugin); } } } return plugins; }这段代码里几个参数值得单独说。SearchOption.TopDirectoryOnly表示只扫当前目录不递归子目录——插件目录如果按功能分子文件夹这里要改成AllDirectories但随之而来的是同名 DLL 冲突风险。GetExportedTypes()在遇到某个类型引用了缺失的依赖时会整体抛ReflectionTypeLoadException这是新手最常遇到的「明明 DLL 在却加载失败」后面避坑章节会专门讲。Activator.CreateInstance返回object用is IPlugin做一次模式匹配既完成类型转换又顺手过滤掉构造失败返回 null 的情况。2.2 契约接口怎么设计决定了这套骨架能活多久反射加载本身只有几十行真正决定这套模板能不能长期用的是契约接口的设计。我见过太多项目把IPlugin写成一个大杂烩结果每加一个插件就要改接口宿主跟着重编译插件化的意义直接归零。一个能扛住迭代的契约通常拆成三层。第一层是元数据让宿主知道这个插件叫什么、版本多少、作者是谁用于在插件管理界面里展示。第二层是生命周期至少要有Initialize和Shutdown让宿主能在启动和退出时给插件分配和释放资源。第三层才是业务入口比如返回一个UserControl或者一个命令集合宿主拿到之后挂到菜单或标签页上。// IPlugin.cs —— 契约接口宿主与插件共享此程序集 public interface IPlugin { // 元数据宿主用于展示和排序 string Name { get; } string Version { get; } string Description { get; } // 生命周期宿主控制插件的启停 void Initialize(IPluginContext context); void Shutdown(); // 业务入口返回可挂载的 WPF 控件 UserControl CreateView(); } // 上下文接口把宿主能力以受控方式暴露给插件 public interface IPluginContext { void Log(string message); T? GetServiceT() where T : class; }这里IPluginContext是个关键设计。插件不应该直接引用宿主的具体类否则又变成强耦合。宿主实现一个PluginContext把日志、配置、服务定位这些能力通过接口暴露出去插件只认接口。这样宿主内部怎么重构插件都不受影响。CreateView返回UserControl而不是Window是因为插件视图通常要嵌进主窗口的某个区域返回Window会导致弹出独立窗口破坏整体布局。契约程序集本身要单独建一个类库项目宿主和所有插件都引用它且这个 DLL 在输出目录里只能有一份。这是整个方案的地基地基歪了上面盖多高都会塌。3. 从零搭一套能跑的骨架宿主、加载器与第一个插件3.1 宿主工程的目录结构与项目引用关系动手之前先把工程结构定下来后面所有代码都往这个结构里填。我一般会建三个项目PluginHostWPF 主程序、PluginContract类库放接口、SamplePlugin类库放示例插件。三者的引用关系是PluginHost引用PluginContractSamplePlugin引用PluginContractPluginHost不引用SamplePlugin。最后这条是整个插件化的核心——宿主在编译期完全不认识任何具体插件。输出目录要特别处理。默认情况下SamplePlugin.dll会生成到它自己的bin目录宿主运行时扫不到。常见做法是在SamplePlugin.csproj里把输出路径改到宿主的插件目录!-- SamplePlugin.csproj 关键配置 -- PropertyGroup TargetFrameworknet8.0-windows/TargetFramework UseWPFtrue/UseWPF !-- 输出到宿主的 Plugins 目录方便调试 -- OutputPath..\PluginHost\bin\Debug\net8.0-windows\Plugins\/OutputPath AppendTargetFrameworkToOutputPathfalse/AppendTargetFrameworkToOutputPath /PropertyGroupTargetFramework必须和宿主一致net8.0-windows里的-windows后缀不能省因为插件里要用 WPF 的UserControl。UseWPF设为 true 才会引入 WPF 相关程序集。AppendTargetFrameworkToOutputPath设为 false 是为了让输出路径干净不然会多出一层net8.0-windows文件夹扫描时容易漏。宿主这边主窗口里放一个TabControl或者ContentControl作为插件视图的容器再放一个按钮触发加载。加载时机一般选在窗口Loaded事件里太早的话 UI 还没准备好插件视图挂上去可能出问题。3.2 加载器加上异常隔离别让一个坏插件拖垮整个宿主第 2 章那段加载代码是理想情况真实项目里必须加异常隔离。一个插件如果引用了缺失的 DLLGetExportedTypes()会直接抛异常把整个加载循环打断后面本来正常的插件也加载不了。正确做法是把每个程序集的加载包在 try-catch 里失败就记录日志跳过。// PluginLoader.cs —— 带异常隔离的加载 public IReadOnlyListIPlugin LoadPlugins(string pluginDirectory, IPluginContext context) { var plugins new ListIPlugin(); if (!Directory.Exists(pluginDirectory)) { context.Log($插件目录不存在{pluginDirectory}); return plugins; } foreach (var dllPath in Directory.GetFiles(pluginDirectory, *.dll)) { try { var assembly Assembly.LoadFrom(dllPath); Type[] types; try { types assembly.GetExportedTypes(); } catch (ReflectionTypeLoadException ex) { // 部分类型加载失败时仍取出成功的那些 types ex.Types.Where(t t ! null).ToArray()!; context.Log(${Path.GetFileName(dllPath)} 部分类型加载失败已跳过); } foreach (var type in types.Where(t typeof(IPlugin).IsAssignableFrom(t) !t.IsAbstract !t.IsInterface)) { try { if (Activator.CreateInstance(type) is IPlugin plugin) { plugin.Initialize(context); plugins.Add(plugin); context.Log($已加载插件{plugin.Name} v{plugin.Version}); } } catch (Exception ex) { context.Log($插件 {type.FullName} 实例化失败{ex.Message}); } } } catch (BadImageFormatException) { // 非托管 DLL静默跳过 } catch (Exception ex) { context.Log(${Path.GetFileName(dllPath)} 加载失败{ex.Message}); } } return plugins; }这里有三层 try-catch每层职责不同。最外层捕获Assembly.LoadFrom的失败BadImageFormatException单独处理是因为插件目录里经常混进原生 DLL这不是错误跳过就行。中间层捕获ReflectionTypeLoadException它的Types属性里失败的位置是 null过滤掉就能拿到部分成功的类型。最内层捕获实例化和Initialize的异常保证一个插件初始化失败不影响其他插件。IPluginContext在这里的作用就体现出来了——加载器不直接写日志而是通过上下文接口输出宿主想换成文件日志、UI 日志还是调试输出改一处实现即可。3.3 写一个最小插件验证整条链路骨架搭好之后写一个最简单的插件来验证。这个插件只做一件事显示一个带按钮的界面点按钮弹出一个消息框。// SamplePlugin.cs —— 最小可运行插件 public class HelloPlugin : IPlugin { private IPluginContext? _context; public string Name 示例插件; public string Version 1.0.0; public string Description 用于验证插件加载链路; public void Initialize(IPluginContext context) { _context context; _context.Log(示例插件初始化完成); } public void Shutdown() { _context?.Log(示例插件已卸载); } public UserControl CreateView() { var button new Button { Content 点我, Width 120, Height 40, Margin new Thickness(20) }; button.Click (_, _) MessageBox.Show($来自 {Name} 的问候); return new UserControl { Content button }; } }这个类必须 public必须有公开无参构造函数这里没写构造函数编译器会生成默认的必须实现IPlugin全部成员。CreateView里用代码构造 UI 是为了减少示例的 XAML 依赖真实项目里通常是new HelloView()HelloView是一个UserControl的 XAML 文件。宿主端把加载到的插件视图挂到界面上// MainWindow.xaml.cs —— 加载并挂载插件 private void OnWindowLoaded(object sender, RoutedEventArgs e) { var context new PluginContext(LogTextBox); var loader new PluginLoader(); var pluginDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Plugins); var plugins loader.LoadPlugins(pluginDir, context); foreach (var plugin in plugins) { var tab new TabItem { Header plugin.Name, Content plugin.CreateView() }; PluginTabControl.Items.Add(tab); } context.Log($共加载 {plugins.Count} 个插件); }AppDomain.CurrentDomain.BaseDirectory拿到的是宿主 exe 所在目录拼上Plugins就是插件目录。每个插件创建一个TabItem标题用插件的Name内容用CreateView()返回的控件。跑起来之后你应该能看到一个标签页点按钮弹出消息框。如果标签页没出现先看日志输出再检查Plugins目录里到底有没有 DLL。4. 避坑与排查反射加载插件时最容易翻车的五个地方4.1 现象DLL 明明在目录里日志却报「未能加载文件或程序集」原因几乎总是依赖缺失。你的插件 DLL 引用了某个第三方库但那个库的 DLL 没被复制到插件目录。反射加载时 CLR 会去解析依赖找不到就抛FileNotFoundException而GetExportedTypes()会把它包装成ReflectionTypeLoadException外层看到的错误信息往往很模糊。解决办法分两步。先看ReflectionTypeLoadException.LoaderExceptions属性里面每个元素都是具体的加载失败原因能直接告诉你缺哪个程序集。然后在插件项目的 csproj 里确认依赖项的Private属性在 VS 里是「复制本地」设为 true保证依赖 DLL 跟着输出。如果依赖是宿主已经引用的公共库可以考虑把插件目录加到程序集解析路径里避免重复加载。4.2 现象改了插件代码重新编译运行起来还是旧逻辑这是Assembly.LoadFrom的缓存机制导致的。同一个路径的程序集第二次LoadFrom会直接返回内存里已加载的那份磁盘上的新文件根本不读。开发阶段反复调试时这个坑特别烦。解决方式有两种。调试期最简单的是每次改完代码重启宿主进程虽然笨但绝对可靠。要做真正的热更新就得用AssemblyLoadContext.NET Core 及以上创建独立的加载上下文卸载时调用Unload()下次加载走新的上下文。注意AssemblyLoadContext的卸载是协作式的只有当上下文里所有对象都没有外部引用时才会真正释放插件视图如果被 WPF 的可视化树持有引用卸载会失败。这是热更新最难的部分模板阶段建议先不做把重启方案用熟。4.3 现象IsAssignableFrom返回 false插件类明明实现了接口九成是契约程序集被加载了两份。宿主引用了一份PluginContract.dll插件目录里又放了一份CLR 从两个不同路径加载同名程序集类型身份就不一致了。typeof(IPlugin)来自宿主那份插件类实现的IPlugin来自插件目录那份两者在 CLR 眼里是两个类型。排查方法是在匹配失败的地方打印type.AssemblyQualifiedName和typeof(IPlugin).AssemblyQualifiedName对比两者的程序集全名。解决方法是确保PluginContract.dll在输出目录里只有一份插件项目引用契约时把Private设为 false不复制本地让它用宿主提供的那份。或者更彻底一点把契约程序集放到宿主 exe 同目录插件目录里不放。4.4 现象插件视图挂上去之后界面错位、样式丢失WPF 的资源查找是沿着可视化树向上走的。插件视图作为一个独立UserControl它的App.xaml里定义的全局样式在宿主里根本不存在因为宿主加载的是自己的App.xaml。插件里写的StaticResource引用如果指向插件自己的资源字典而那个字典没被合并进宿主就会抛资源找不到的异常。常见做法是让插件把自己的资源字典以ResourceDictionary的形式暴露出来宿主在加载插件时把它合并进Application.Current.Resources.MergedDictionaries。或者约定插件视图的样式全部内联不依赖外部资源。前者更规范后者更省事看项目规模选。另外UserControl的尺寸如果写死嵌进TabControl时可能被拉伸或裁剪建议用MinWidth/MinHeight配合自适应布局。4.5 现象插件初始化时访问宿主服务报空引用Initialize被调用的时机是在Activator.CreateInstance之后、插件加入列表之前。如果插件在构造函数里就访问IPluginContext那时候Initialize还没执行_context还是 null。构造函数里只做字段初始化所有需要上下文的操作都放到Initialize里这是契约设计时就该定好的规矩。另一个相关问题是IPluginContext.GetServiceT()返回 null。宿主实现上下文时服务注册往往在插件加载之后才完成导致插件拿不到服务。解决办法是把服务注册提前到插件加载之前或者在上下文里做延迟解析插件真正用到服务时才去查。模板阶段建议把服务注册放在App.OnStartup里早于主窗口的Loaded事件。5. 让这套模板真正能上项目契约版本管理与插件隔离的进阶做法模板跑通只是起点要上真实项目还得解决两个问题契约接口改了怎么办以及插件之间怎么互不干扰。契约版本管理我一般用「接口只增不改」的原则。IPlugin一旦发布就冻结新能力通过新增可选接口来实现比如IConfigurablePlugin、IAsyncPlugin。加载器在匹配时先判断基础接口再判断可选接口插件实现哪个就启用哪个能力。这样老插件不用改代码就能继续跑新插件按需实现新接口。版本号放在IPlugin.Version里宿主可以据此决定是否加载某个插件或者提示用户升级。// 可选接口示例支持异步初始化的插件 public interface IAsyncPlugin : IPlugin { Task InitializeAsync(IPluginContext context); } // 加载器里按能力分支处理 if (plugin is IAsyncPlugin asyncPlugin) { await asyncPlugin.InitializeAsync(context); } else { plugin.Initialize(context); }插件隔离方面如果插件数量多、依赖复杂建议每个插件用独立的AssemblyLoadContext加载。这样插件 A 引用的Newtonsoft.Json12.0 和插件 B 引用的 13.0 可以共存不会互相覆盖。代价是跨上下文的类型转换会变复杂契约接口所在的程序集必须由宿主上下文共享不能各自加载。实现上就是自定义一个PluginLoadContext : AssemblyLoadContext重写Load方法对契约程序集返回 null表示用默认上下文的对其他程序集走自己的解析逻辑。验证这套骨架是否真的可用我有个习惯故意写一个会抛异常的插件一个引用缺失依赖的插件一个正常插件三个一起放进目录看宿主能不能正常加载那个好的、跳过两个坏的、并且在日志里说清楚原因。能通过这个测试说明异常隔离做到位了。另一个习惯是每次改完契约接口把老插件 DLL 原封不动放回去跑一遍确认向后兼容没被破坏。这两条血泪经验帮我省过很多次线上事故希望帮到你。本文还有配套的精品资源点击获取