.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 里值的文件路徑

       1./Files/lc329857895/AddInTest.rar

       2./Files/lc329857895/AddInsSample.rar