简介面向C#/.NET桌面开发者的WPF插件式动态加载示例源码包特别适合需要在不重新编译主程序的情况下扩展功能模块的场景。源码完整演示了插件式开发的主要流程从插件目录查找并加载DLL程序集通过反射遍历类型、按接口或基类筛选插件再以创建实例的方式注册进插件容器方便主程序随时调用同时包含异常处理与独立AppDomain卸载机制保证插件运行稳定并可安全释放整体可直接作为工程模板套用。压缩包共135个文件大小约477KB核心内容为34个C#源文件、2个XAML界面文件及6个项目文件另有程序集、调试符号、配置与可执行文件等辅助内容结构清晰便于对照学习与二次修改。已有227人学习下载适合中高级C#开发者参考其中示例工程快速掌握反射动态加载与插件架构落地写法。1. 插件式DLL动态加载一个接口加一个加载器解决的不只是解耦做中大型 WPF 应用做到业务模块一多最难受的不是写代码而是每次加功能都要把整个客户端重新编译、重新发布。插件式 DLL 动态加载做的事情其实很收敛把每个功能体拆成独立 DLL宿主程序启动时扫一遍插件目录用反射找到实现了统一接口的类型实例化后直接挂到界面上。这套源码的价值在于你不需要从架构论证开始慢慢推直接把它当模板改改命名空间和业务类就能拿到一个可以扩展的框架。适合三类人正在做模块化重构的 WPF 项目负责人、想给内部工具集加自动扩展能力的开发者、以及准备入手插件式架构但不想一上来就碰 MEF 这类重型框架的人。下面我按这套模板最常见的结构来拆先立接口约定再写加载器接着把插件接到 WPF 界面最后把最容易翻车的几个坑一次说透。2. 动手前想清楚三件事接口契约、程序集加载方式、类型扫描策略很多人拿到插件式模板第一反应是去写加载代码但真正决定项目后期生死的往往是前面这几步设计。插件式 DLL 动态加载从表面看是“反射”两个字背后其实是程序集边界和类型发现的问题。这一章先把三个关键决策讲明白中间会带上可用的代码片段到下一章再拼成完整的最小实现。2.1 接口契约为什么 IPlugin 一定要放在独立程序集里插件式架构的地基不是加载器而是接口。我一般会先建一个独立类库项目叫Sdk.Contracts里面只放接口和几个轻量 DTO。宿主程序和插件程序集都只引用这个 Contracts谁也不依赖谁。// Sdk.Contracts/Contracts/IPlugin.cs namespace Sdk.Contracts; /// summary插件必须实现的统一契约/summary public interface IPlugin { /// summary全局唯一标识用于去重和路由/summary string Key { get; } /// summary显示名称直接绑到界面上/summary string Name { get; } /// summary插件版本号/summary string Version { get; } /// summary执行入口异步签名避免在 UI 线程卡死/summary TaskPluginResult ExecuteAsync(PluginContext context); } /// summary执行结果。不要直接返回 object定义越死主程序越好处理/summary public sealed class PluginResult { public bool Success { get; set; } public string Message { get; set; } string.Empty; } /// summary上下文对象。后续要加参数、加服务都从这里扩/summary public sealed class PluginContext { public IReadOnlyDictionarystring, object Parameters { get; set; } new Dictionarystring, object(); }这段代码的逻辑很直白IPlugin只暴露名称、版本和执行入口PluginContext作为主程序向插件传参的通道PluginResult统一收口返回值。这样设计有几个必须坚持的理由。接口独立成项目后宿主程序集不包含IPlugin类型插件 DLL 引用它时也就不会反向依赖宿主这直接杜绝了循环引用问题。如果图省事把接口写在主程序里插件就得引用主程序集而主程序在运行时又加载插件程序集之间绕成闭环后续每次改接口都要同时重新编译主程序和所有插件插件式架构就名存实亡了。另一个经验是接口方法签名里不要出现任何 WPF 类型比如Window、Control。插件是独立程序集一旦用它引用System.Windows.Forms或界面控件类型插件就跟主界面深度绑定想单独测试插件或者无人值守运行时调用就全废了。接口参数和返回值尽量用基本类型、字符串、自定义 DTO跨程序集传递数据才干净。接口要留扩展余地但别过度设计。有人一上来就加Initialize、Shutdown、Configure一大套生命周期方法模板里先不用做这么重。给出ExecuteAsync一个入口就好初始化工作放构造函数或首次执行时懒加载都能做等真有插件需要常驻内存再扩展生命周期接口到时加一个IRunnablePlugin派生接口即可对旧插件无感。2.2 Assembly.LoadFrom 是默认选择三种加载方式的取舍接口定义了接下来是程序集加载。C# 里反射加载 DLL 主要有三种方式Assembly.Load、Assembly.LoadFrom、Assembly.LoadFile。很多教程一笔带过但这里选错后面一定踩坑。加载方式加载依据依赖解析典型问题Assembly.Load程序集名称AssemblyName按默认探测路径找依赖不在宿主同目录的 DLL 找不到Assembly.LoadFrom文件路径能按 DLL 所在目录解析依赖同名不同版本程序集可能被复用Assembly.LoadFile文件路径基本不解析依赖插件依赖的同目录 DLL 常加载失败模板里选Assembly.LoadFrom是最稳的起点。它会把程序集加载到默认加载上下文后续 DLL 引用其他依赖时CLR 会优先按已加载程序集匹配找不到再去插件 DLL 所在目录探测。对“一个插件目录放一套 DLL”的常规布局完全够用。Assembly.LoadFile是个典型陷阱。它加载文件但不把插件目录加入依赖探测范围插件依赖的第三方 DLL 不会被自动找到接下来就是各种FileNotFoundException。Assembly.Load按名称加载放则要求程序集已经被下载到某处或已在宿主加载上下文里反而不适合做目录扫描。所以除非你有极强的隔离需求否则默认LoadFrom。补充一个重要细节这段模板代码里还应当挂一个AppDomain.AssemblyResolve事件做兜底。插件可能引用了一个宿主没有、也不在插件目录的 DLL此时程序集会尝试从宿主基目录、全局程序集缓存找找不到就抛异常。事件里可以按名记录到日志至少知道缺的是哪个体反向排查快很多。2.3 类型扫描怎么从程序集里捞出我要的那个 IPlugin程序集加载完第二步是遍历类型找到实现了IPlugin的具体类。这里有个常见误区直接assembly.GetTypes()一把梭然后被异常打懵。var pluginInstances new ListIPlugin(); foreach (var dllPath in Directory.GetFiles(pluginDir, *.dll)) { Assembly assembly; try { assembly Assembly.LoadFrom(dllPath); } catch (BadImageFormatException) { // 同目录可能有非托管 DLL 或杂项资源跳过 continue; } Type[] types; try { types assembly.GetTypes(); } catch (ReflectionTypeLoadException ex) { // 插件缺依赖时 GetTypes 会抛这个先记录缺失项再取能用的部分 types ex.Types?.Where(t t ! null).ToArray() ?? Array.EmptyType(); } foreach (var type in types) { if (type.IsClass !type.IsAbstract !type.IsGenericTypeDefinition typeof(IPlugin).IsAssignableFrom(type)) { var plugin Activator.CreateInstance(type) as IPlugin; if (plugin ! null) { pluginInstances.Add(plugin); } } } }逐个解释这段代码的关键判断。BadImageFormatException很常见插件目录里混入原生 DLL、配置文件甚至别的托管程序集都会抛这个异常直接跳过最省事。GetTypes()不是一定安全的插件依赖缺失时抛的是ReflectionTypeLoadException它的Types属性仍然包含加载出的部分类型过滤掉null再继续用比整体放弃强得多。类型判定上按IsClass、!IsAbstract、!IsGenericTypeDefinition、typeof(IPlugin).IsAssignableFrom(type)四个条件一次过滤不要用GetInterface(IPlugin)去字符串匹配接口名一旦命名空间调整就断了。实例化用Activator.CreateInstance(type)而不是new因为你拿到的Type不是编译期可确定的类型反射创建是唯一通用方式。插件默认构造函数必须公开否则这里会抛MissingMethodException。做完这一步pluginInstances就是所有可运行插件的实例集合下一章把它接进 WPF 界面。3. 从空工程跑通最小实现宿主扫描、插件工程与界面绑定上一章把接口和加载机制讲清楚了这一章直接拼一套可运行的最小代码。最终效果是启动宿主程序后自动扫描Plugins目录把插件显示在 WPF 窗口左侧点按钮执行插件并返回结果。整段按“宿主侧、插件侧、界面侧”三个层次展开每一层都有完整代码和参数说明。3.1 宿主导航扫目录、去重、缓存已加载插件宿主工程先建一个PluginLoader类职责统一加载插件目录、缓存实例、提供查询能力。这里有一个容易忽略的稳健设计每次扫描前先清空缓存并把已加载程序集记录到 HashSet避免重复实例化。// Host/Services/PluginLoader.cs public sealed class PluginLoader { private readonly string _pluginDir; private readonly HashSetstring _loadedKeys new(); private readonly ListIPlugin _plugins new(); public PluginLoader() { _pluginDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Plugins); } public void ScanAll() { _plugins.Clear(); _loadedKeys.Clear(); if (!Directory.Exists(_pluginDir)) { Directory.CreateDirectory(_pluginDir); return; } foreach (var dllPath in Directory.GetFiles(_pluginDir, *.dll)) { try { var assembly Assembly.LoadFrom(dllPath); var types assembly.GetTypes(); foreach (var type in types) { if (type.IsClass !type.IsAbstract typeof(IPlugin).IsAssignableFrom(type)) { var instance Activator.CreateInstance(type) as IPlugin; if (instance null) continue; if (!_loadedKeys.Add(instance.Key)) { // 两个插件声明了相同的 Key后加载的丢弃 continue; } _plugins.Add(instance); } } } catch (BadImageFormatException) { // 非托管 DLL直接跳过 } catch (ReflectionTypeLoadException ex) { // 记录依赖缺失信息便于排错 foreach (var loaderEx in ex.LoaderExceptions ?? Array.EmptyException()) { Debug.WriteLine(loaderEx?.Message); } } } } public IReadOnlyListIPlugin Plugins _plugins; }这个类做了三层防护。第一层Directory.CreateDirectory保证宿主首次启动时插件目录一定存在不会因为目录缺失静默返回。第二层用_loadedKeys拦截重复 Key插件按 Key 去重而不是按类型名去重这样即使两个程序集里存在同名类也能区分。第三层单独捕获ReflectionTypeLoadException并把LoaderExceptions输出到调试窗口LoaderExceptions里能看到具体缺了哪个依赖文件上线排错时不用盲猜。_plugins里直接保存的是实例不是 Type。这一点要刻意为之插件数量限制在几十个以内实例化成本极低保留实例可以避免每次操作都做一次反射创建而且插件实例加入列表后主程序可以可靠地保持同一个实例执行多次插件内部状态才有意义。3.2 插件侧类库项目 编译事件自动输出到 Plugins 目录插件侧是一个独立的类库项目只引用Sdk.Contracts。下面新建一个插件项目项目文件.csproj里加上编译后自动复制 DLL 的目标这个配置能省掉你手动拷贝驱动的麻烦。Project SdkMicrosoft.NET.Sdk PropertyGroup TargetFrameworknet8.0-windows/TargetFramework Nullableenable/Nullable ImplicitUsingsenable/ImplicitUsings !-- 注意按宿主实际目标框架写两边不一致会加载失败 -- /PropertyGroup ItemGroup ProjectReference Include..\Sdk.Contracts\Sdk.Contracts.csproj / /ItemGroup Target NameCopyToHostPlugins AfterTargetsBuild !-- 把编译产物复制到宿主输出的 Plugins 下路径按实际工程位置调整 -- Copy SourceFiles$(TargetDir)\$(AssemblyName).dll DestinationFolder$(SolutionDir)\Host\bin\Debug\Plugins\ SkipUnchangedFilestrue / /Target /ProjectTarget在Build之后执行把$(TargetDir)插件编译输出目录里的 DLL 拷到宿主输出目录的 Plugins 文件夹。SkipUnchangedFilestrue避免每次编译都全量覆盖开发时体验好很多。插件实现类代码则很简单。项目里新建一个类实现IPlugin方法体里写你自己的业务逻辑即可。// MyPlugin/Services/TimePlugin.cs using Sdk.Contracts; namespace MyPlugin; public sealed class TimePlugin : IPlugin { public string Key time-plugin; public string Name 当前时间; public string Version 1.0.0; public TaskPluginResult ExecuteAsync(PluginContext context) { var now DateTime.Now; var result new PluginResult { Success true, Message $插件运行中当前时间{now:yyyy-MM-dd HH:mm:ss} }; return Task.FromResult(result); } }插件类命名空间可以随便定扫描时机不依赖命名空间只看IPlugin接口。但建议Key写成全局唯一字符串比如company.module.function的格式这样后续做插件去重和路由时天然可读。ExecuteAsync用Task.FromResult包结果保持方法签名是异步的将来插件真的要做耗时操作时只需在方法内部换用真正的异步逻辑主程序无需改动。3.3 WPF 界面绑定用 ItemsControl 显示插件列表用 Command 触发执行插件列表拿到后接下来是把它们呈现到 WPF 界面。我通常不在这里写死循环构建 UI而是用一个MenuViewModel持有插件列表和运行命令再用ItemsControl DataTemplate把数据映射成按钮列表。这样界面和数据完全解耦也方便以后把插件列表改成菜单、工具栏或功能区。// Host/ViewModels/MainViewModel.cs public sealed class MainViewModel : BindableBase { private readonly PluginLoader _loader new(); public ObservableCollectionIPlugin Plugins { get; } new(); public AsyncRelayCommandIPlugin RunCommand { get; } public MainViewModel() { RunCommand new AsyncRelayCommandIPlugin(RunPluginAsync); LoadPlugins(); } private void LoadPlugins() { _loader.ScanAll(); Plugins.Clear(); foreach (var p in _loader.Plugins) { Plugins.Add(p); // 插件实例直接作为列表项 } } private async Task RunPluginAsync(IPlugin plugin) { var result await plugin.ExecuteAsync( new PluginContext()); MessageBox.Show(${plugin.Name} 执行完成{result.Message}); } }对应 XAML 里把ItemsControl的ItemsSource绑到Plugins列表项里放三列插件名、版本、运行按钮。这里要特别说明按钮的绑定方式因为DataTemplate内部的DataContext已经是插件实例了要用RelativeSource回溯到外层ItemsControl的DataContext才能访问到主视图模型的RunCommand。Window ... d:DataContext{d:DesignInstance TypeviewModels:MainViewModel} Grid Border DockPanel.DockLeft Width240 Background#F5F5F5 ItemsControl ItemsSource{Binding Plugins} ItemsControl.ItemTemplate DataTemplate Border Margin8 Padding8 BackgroundWhite CornerRadius4 Grid Grid.RowDefinitions RowDefinition HeightAuto/ RowDefinition HeightAuto/ RowDefinition HeightAuto/ /Grid.RowDefinitions TextBlock Grid.Row0 Text{Binding Name} FontWeightSemiBold/ TextBlock Grid.Row1 Text{Binding Version} ForegroundGray FontSize12/ Button Grid.Row2 Content执行 HorizontalAlignmentLeft Padding8,4 Command{Binding DataContext.RunCommand, RelativeSource{RelativeSource AncestorTypeItemsControl}} CommandParameter{Binding}/ /Grid /Border /DataTemplate /ItemsControl.ItemTemplate /ItemsControl /Border /Grid /Window这个绑定结构是 WPF 数据绑定里的经典写法。ItemsSource{Binding Plugins}让列表数据源来自 ViewModelCommand绑定通过RelativeSource向上找到ItemsControl取其DataContext即MainViewModel中的RunCommandCommandParameter{Binding}把当前插件实例传给命令参数。三个绑定配合界面完全不写Code-Behind事件插件列表增删时界面自动刷新。需要提醒的是这里插件的ExecuteAsync直接跑在 UI 线程的异步命令里。如果插件内部有重度计算命令虽为异步但 await 前那段同步代码仍会卡界面稳妥做法是在 ViewModel 里再包一层Task.Run把插件执行整体丢到线程池。模板里先保留简单实现后面第 5 章进阶部分会说性能和安全加固。4. 反射加载 DLL 的五条踩坑记录从 DLL 冲突到插件资源失效模板能跑通只是第一步真正接入业务后以下这些话才会逐渐暴露出来。这章记录五个最常见且破坏力最大的坑按“现象 → 原因 → 解决”的顺序写每条都来自实际项目排查经验。4.1 DLL 冲突插件 A 和插件 B 引用了同名但不同版本的依赖现象先加载插件 A再加载插件 BB 运行时抛FileLoadException或TypeLoadException提示某程序集版本不匹配把加载顺序换一下报错方对调。原因CLR 进程内已存在同名程序集时再遇到同名的Assembly.LoadFrom会优先返回已加载的那个实例而不会按版本重新加载。插件 A 先用了依赖库的 1.x 版本插件 B 需要 2.x第二个就被降级或版本不匹配。解决优先让插件目录按“每个插件一个子文件夹”组织即Plugins/PluginA/*.dll、Plugins/PluginB/*.dll这样可以配合AssemblyLoadContext或独立AppDomain做隔离若只在 .NET Framework 下短期方案是统一依赖版本在插件开发约定里明确“一个插件目录整套拷贝”并把版本不一致列为验收阻塞项。4.2 已加载的 DLL 被文件锁占用热更新插件必须重启应用现象第一次加载插件后替换插件目录里的 DLL抛 IOException“文件正在使用”进程不退就换不掉。原因Assembly.LoadFrom装载后CLR 会把该文件保持映射Windows 文件句柄不释放。这是托管进程的默认行为不是代码 bug。解决开发期把插件项目“重新编译 复制 DLL”改成“在宿主已停止状态下构建”或直接在 Visual Studio 里设置生成事件后重启宿主进程。运行期做热更新务实方案是把插件加载放进独立AppDomain.NET Framework或AssemblyLoadContext.NET Core / .NET 5卸载上下文时再卸载程序集但插件对象和后台线程必须全部释放干净。如果只是内部工具更新策略写成“提示用户下次启动时生效”反而更稳定。4.3 ReflectionTypeLoadException 出现但类型列表为空真实原因藏在 LoaderExceptions现象GetTypes()抛异常外层 try/catch 只拿到ReflectionTypeLoadException打印Message根本看不出缺什么类型扫描结果为空界面上一片空白。原因GetTypes()加载某个类型时需要该类型的基类和接口类型可获。插件依赖的第三方 DLL 没有随插件复制到Plugins目录类型加载就会失败。异常对象里真正有价值的是LoaderExceptions数组每一项包含缺失文件的具体错误。解决除了Debug.WriteLine上线环境还要把LoaderExceptions写入日志文件。排查时看见Could not load file or assembly Newtonsoft.Json就知道是依赖没拷全。这也是第 3.1 节代码里单独兜住该异常的原因——不处理它整个插件目录都会被认为“不可用”而不是只跳过有问题的插件。4.4 插件里带资源字典样式/主题主窗口加载不到现象插件项目里放了一个ResourceDictionary代码里通过pack://URI 引用展开后资源丢失或抛IOException。原因pack://URI 里写的程序集名必须正确指到插件程序集但很多人在插件代码里直接写pack://application:,,,/Themes/Style.xaml它默认解析的是宿主程序集而不是插件程序集。解决统一写成pack://application:,,,/MyPlugin;component/Themes/Style.xamlMyPlugin是插件程序集名;component之后是相对路径。也推荐在插件代码中用Assembly.GetExecutingAssembly()定位并以流方式加载资源字典然后合并进宿主资源路径写错时至少能立刻看到是哪个程序集的问题。var uri new Uri( pack://application:,,,/MyPlugin;component/Themes/Style.xaml, UriKind.Absolute); var resourceDict (ResourceDictionary)Application.LoadComponent(uri); Application.Current.Resources.MergedDictionaries.Add(resourceDict);这段代码放在插件初始化时执行把它合并到全局资源中。注意插件一旦卸载全局资源里的字典不会自动移除属于把资源合并进宿主的“一次性动作”插件常驻场景下无影响。4.5 ExecuteAsync 在 UI 线程上构造插件一慢界面就假死现象点“执行”按钮后界面卡顿数秒插件运行完才恢复响应。原因AsyncRelayCommand虽然 await 了ExecuteAsync但调用它之前plugin.ExecuteAsync(new PluginContext())本身已经被调用来创建 Task。若插件构造函数或同步代码里做了数据库重查询或者ExecuteAsync里没真正 async同步段全部跑在 UI 线程上界面必然卡死。解决约定插件的ExecuteAsync实现必须保证内部无长同步段宿主侧再加一道防线把执行放入Task.Runprivate async Task RunPluginAsync(IPlugin plugin) { var result await Task.Run(() plugin.ExecuteAsync(new PluginContext())); MessageBox.Show(${plugin.Name} 执行完成{result.Message}); }Task.Run把同步部分移到线程池UI 线程只等结果回来注意MessageBox还在 await 之后跑回 UI 线程。这样做牺牲了一点纯粹性换回来的防卡死能力非常值。5. 从模板到正式框架我会先加这四道保险模板能让你一天跑通但正式接入业务前我还会做四件事。第一道保险是显式版本校验加载时读assembly.GetName().Version与接口约定的最低版本比较版本不达标的插件不进列表并在日志里标黄。第二道保险是异常隔离前文说过可以捕获单个插件的异常并继续加载其余插件正式版里要再做的不是 Debug 打印而是写结构化日志。第三道保险是把执行从Task.Run升级为带取消令牌的版本插件轮询CancellationToken才能在被用户点击“取消”时及时退出模板里PluginContext加一个CancellationToken属性即可不破坏旧插件。第四道保险关乎性能反射获取类型是有开销的对几百个插件的规模可忽略但如果你把插件数量做到上千扫描一次就可能上百毫秒这时就该加一层元数据缓存——把类型全名、程序集路径存到本地文件下次启动只做一次快速比对而不是重新GetTypes()。验证方法也很重要。我最常用的验收清单是三条冷启动扫描一个空目录不报错放入一个正常插件和一个故意缺依赖的插件系统能加载前者并跳过后者同目录替换插件 DLL 后重启新版本生效且版本号正确显示。这三条过了插件式基础框架就能扛住日常开发。插件式 DLL 动态加载是个越用越顺手的方向。我从最初手写加载器踩坑到现在基本固定成一套模板最大的体会是不要追求一次把架构做完全接口保持最小、加载保证健壮、异常能定位问题剩下的事交给业务去长。希望这套思路能帮你少走弯路。资源获取及二次开发建议拿到的模板压缩包解压后建议先按“Contracts → Plugin → Host”的顺序打开三个工程。第一次编译时先编译 Contracts再编译插件项目让其触发复制目标把 DLL 送入宿主输出目录最后编译并运行宿主程序。如果编译顺序不对看到的会是宿主运行后插件列表为空——那不是模板坏了是插件 DLL 还没被复制到Plugins目录。把本章第 3 节的三个环节走通这套模板就算正式交接到你手里了。本文还有配套的精品资源点击获取