6

私は自分のアプリケーションにプラグイン サポートを提供するさまざまな方法を探し回っています。理想的には、コア機能を作成し、データのインポート、エクスポートなどのさまざまなプラグイン/アドオンを開発しているさまざまな顧客に基づいています...プラグイン アーキテクチャを介して C# アプリケーションを拡張可能にするために利用できる方法は何ですか?

例を作ってみましょう。メイン メニュー ([ファイル]、[編集]、[表示] など) と、さまざまなブランドの車をメーカー (フォード、GM など) ごとに表示する TreeView を備えたプログラムがあるとします。車を右クリックすると、コンテキスト メニューが表示され、オプションは [車の削除] のみです。

プラグインを展開して、1 人の顧客が TreeView で新しいブランド (たとえばホンダ) を表示できるようにアプリケーションを開発し、さらに車のコンテキスト メニューを拡張して、「車を塗装する」ことができるようにするにはどうすればよいでしょうか。 '?

Eclipse/RCP 開発では、これは拡張ポイントとプラグインによって簡単に処理されます。C# はそれをどのように処理しますか? 私は独自のプラグイン アーキテクチャを開発し、MEF について調べています。

4

2 に答える 2

10

MEFは、開始するのに適した場所です。

Glenn Block の記事Managed Extensibility Framework: Building Composable Apps in .NET 4 with the Managed Extensibility Frameworkは、概要を説明しています。

ところで、タイトルに惑わされないでください。MEF for .NET 3.5 SP1 も入手できます。

于 2010-06-01T12:58:31.980 に答える
1

Visual Studio 2010 は MEF を使用しているため、これが MS で推奨される方法であると確信しています。 System.Addinは常に少し重いように見えましたが、アドインが常に機能する必要があり、コードベースが常に進化している場合は、より良い選択かもしれません。

アドインの分離に関心がある場合は、AppDomains を読む必要があります。AppDomain here 内でアセンブリを分離する方法を学習するために作成したデモ プロジェクトがあります。興味深いと思われるかもしれません。分離に関する簡単な事実: 型だけが境界を越える必要があり、これらの型は封印され、クロスドメイン イベント処理から叫び声を上げて実行され、アドインは MarshallByRefObject を決して拡張してはなりません。

于 2010-06-01T13:07:11.240 に答える