.NET Framework 3.5提供了一个框架，即System.Addin命名空间，通过该命名空间我们可以进行插件开发，用程序集System.AddIn来保存和创建插件。这个框架也称为Managed AddIn Framework（MAF）。
插件还有其他称呼，如add-on或plug-in。
先前研究过SharpDevelop,SharpDevelop采用框架——插件的可扩展的体系结构，毕竟代码水平比较高，对它的插件开发方式没有学习彻底。
.NET Framework 3.5 的System.Addin命名空间让插件开发变的简单很多了。
1.什么是AddIns
在应用程序运行期间允许动态添加程序集。
插件开发可以在给开发完成的应用程序添加功能。我们可以创建一个主机应用程序，随时间的推移给它添加越来越多的功能这些功能可以是开发团队编写的，也可以由其他供应商也可以创建插件，扩展该应用程序。
2.AddIns（MAF）的设计目标如下
应用程序容易开发插件
在运行期间高效查找插件
开发主机程序应是一个很简单的过程，但不像开发插件那么容易
插件和主机应用程序应独立进行维护和升级
3.MAF体系结构
MAF体系结构基于一个包含7个程序集的管道。这个管道解决了插件的版本问题。因为管道中的程序集之间的依赖性很低，所以合同、主机程序和插件升级到新版本可以完全互不干扰。
其中心是合同程序集。这个程序集包含一个合同接口，其中列出了插件必须实现、可以由主机程序调用的方法和属性。合同的左边是主机端，右边是插件端。图中还 显示了程序集之间的依赖性。最左端的主机程序集与合同程序集没有依赖性，插件程序集与合同程序集也没有依赖性，这两个程序集都没有实现合同定义的接口，只是有一个对视图程序集的引用。主机应用程序引用主机视图；插件引用插件视图。视图包含抽象的视图类，该类定义的方法和属性与合同相同。
下图是上图的中文说明：
下图是插件开发结构类关系图
有了这个模型，插件端和主机端可以完全独立地升级了，只是需要使用映射层。例如，如果主机的一个新版本使用全新的方法和属性，合同就仍可以保持不变，只有适配器需要修改。也可以定义新的合同。适配器可以修改，也可以同时使用几个合同。
下图显示了MAF体系结构的外观为一个单一的插件。如果我们要创造更多的插件（如演示应用程序） ，我们就必须建立新的类来继承插件适配器来完成该功能。
4.插件模型文件夹结构
除了AddIns目录之外，其他目录都直接包含管道特定部分的程序集。AddIns目录为每个插件程序集包含一个子目录。插件也可以保存在完全独立于其他管道组件的目录中。
MAF需要使用反射来动态加载，才能获得插件的所有信息。而且，对于许多插件而言，这还会增加主机应用程序的启动时间。因此，MAF使用一个 高速缓存，来保存管道组件的信息。该高速缓存是由安装插件的程序创建的，如果主机应用程序有管道目录的写入权限，该高速缓存就由主机应用程序创建。
在目录结构中有一个PipelineSegments.store文件，它是一个外接程序，有两个任务：
将有关所有外接程序和管线段的信息注册到缓存文件中。
通过搜索缓存查找外接程序的指定宿主视图的外接程序
在AddIns文件夹里面会有一个Addins.store文件，它的作用就是让程序查找插件显示在应用程序中。
应用插件开发对应用系统来讲确实有很大好处，很多应用程序都使用了插件开发，例如：Visual Studio、Eclipse、还有浏览器IE、FF,虽然我们不是这些软件的开发商，但是我们仍然可以在这些软件里添加我们需要的功能，插件开发更容易维护和升级系统，而且对提高程序运行效率也有很大帮助。
网上关于Addins的示例代码比较少，自己找了两个，大家研究下。
示例程序下载
提示：AddinsSample要修改下HostAppWPF 项目下 Settings.settings 里值的文件路径
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。