良い一日。 あなたの大多数は、アプリケーションの拡張性の問題に遭遇したと思います。 同様に、アセンブリの一部がプログラムのプラグインであるかどうかを確認するために、多くの人がReflectionを掘る必要があったと思います。 .NETアセンブリでは、デフォルトでアプリケーションと同じドメインにロードされ、その後アンロードできなかったという事実は多くの人が嫌いでした。 もちろん、多くはCreateInstanceAndUnwrapを介して別々のドメインにオブジェクトを作成しましたが、これはすべて手作業で行う必要がありました。 一般的に、「マウスは泣き、刺した...」。 System.Addinの登場により、開発者は、これらの問題がなくてもすぐに使える拡張可能なアプリケーションを作成するためのツールを手に入れました。 この技術については、いくつかの記事で説明します。
始める前に、用語を扱いましょう：
ホスト、ホストアプリケーションは、実際には拡張可能なアプリケーションであり、原則として、拡張機能を検索してアクティブにします。
アドイン、拡張機能はホストアプリケーションの追加機能を含むモジュールです
System.Addinの機能
System.Addinとは何ですか？ これは、.NET Framework 3.5に登場した新しい名前空間です。 System.Addinは、その核となる部分で、アプリケーション機能を拡張するためのプログラミングモデルを開発者に提供します。 さらに、このソフトウェアモデルを使用すると、いくつかの重要な機能が提供されます。
1.ホストアプリケーションとアドインには、独立したバージョンがある場合があります。 したがって、以前のバージョンのアプリケーション、またはそれ以降のバージョンのアプリケーション、または一般に別のアプリケーション用にビルドされた拡張アセンブリで動作するホストアプリケーションをビルドできます。
2.必要なレベルの分離およびセキュリティ権限でアドインをアクティブ化する機能。 つまり、プログラムモデルSystem.Addinを使用すると、サードパーティの開発者によって作成された場合でも、アプリケーションのセキュリティを管理できます。 これで、プログラムを圧倒する重要な拡張モジュールはありません。
3.ホストアプリケーションおよびその他の拡張機能からの拡張機能の複数の分離レベルのサポート。 つまり、ドメインまたはプロセスレベルで分離を構築するためのいくつかの可能なシナリオがあり、ホストアプリケーションのセキュリティが強化されます。
4.より便利な寿命管理拡張。 分離はドメインまたはプロセスレベルで使用されるため、プラグインでの作業が完了すると、必要なドメインを単にアンロードするだけで十分です。
わかった いくつかの機能が整理されています。 続けましょう。
建築
System.Addinアーキテクチャ全体は、 アドインパイプラインなどの重要な概念に基づいて構築されています（「拡張パイプライン」と翻訳します）。 実際、このフレーズの下では、すべてが隠されています。 次の図を見て、アーキテクチャに関するすべてを明確にします。
これは、同じアドインパイプラインです。 これらすべてのセグメントにより、パイプラインで必要な抽象化レベルが達成され、分離が保証されます。 さらに詳細に分析します。 パイプラインの最後には、ホストアプリケーションと拡張機能自体があります。 これらは最もおもしろいものではありませんので、次に何があるかを検討してみましょう。
1. 契約 。 図からわかるように、コントラクトはインターフェイスであり、ホストと拡張機能間の「相互作用のプロトコル」であり、それらの共通基盤です。
2.次に、 アダプターがコントラクトの両側に作成され（ビューを継承）、対応するクラスのビューを実装し、ビューが提供するインターフェースでコントラクトをラップします。 また、1つのアセンブリでアドインビューとホストビューを結合しない場合は、1つのアセンブリでホストビューとホストビューを結合できます。 いずれにせよ、私のアドバイス：パイプラインの各セグメントに個別のアセンブリを使用します。 この方法は簡単です。
3.さて、3番目のポイントはプレゼンテーションクラスです （厳密にはインターフェイスまたは継承クラスでなければなりません）。 これらは、ホストと拡張機能の相互作用で使用されるタイプとメソッドの対応する表現です。
この段階では、この情報で十分です。 アドインパイプラインの外観を想像してください。 詳細については、次のいずれかの記事でこのパイプラインの各セグメントの役割を検討します。
また、アーキテクチャには、作成のプロセスで遭遇するいくつかの制限があります。
1.最初に、各コンベアセグメントは、理想的には個別のアセンブリです。 ビューは1つのアセンブリに結合できますが、アダプタが同じ方法で結合される場合のみです。
2.次に、アドイン、アダプター、およびコントラクトはパブリックであり、特別な属性でマークされている必要があります。 以下の図を参照してください。
必須属性は角括弧で示されます。 ご覧のとおり、ホスト側からのビューには特別な属性は必要ありません。
3.第三に、パイプラインが正常に機能するために厳密なフォルダー構造が必要です。
* アドインは、必ずしもアダプター、ビュー、およびコントラクトの隣にあるとは限りません。 拡張機能はどこにでも配置できます。
パイプラインの各セグメントは独自のフォルダーに配置する必要があり、AddInSideAdapters、AddInViews、Contracts、およびHostSideAdaptersフォルダーでは、ネストされたディレクトリの存在が許可されていないことに注意してください。
4.第4に、最も一般的なシナリオは別のドメインで拡張機能をアクティブ化することであるため、設計時に（パラメーターまたは戻り値として）ドメインの境界を越えるオブジェクトをシリアル化できることを忘れないでください。
行くぞ 多かれ少なかれ。 アーキテクチャと制限は一見不必要に複雑に見えるかもしれませんが、実際にはそうではありません。 System.Addinが何であるかを多くの皆さんが理解していると思います
それだけです
次の記事では、System.Addinの使用方法を示す例を示します。