6

私は基本的に、コントロールを使用してページをデザインできるプリロードされたコントロールを備えたデザイナーであるアプリケーションを持っています。

今後、さらに多くのコントロールをリリースする予定です。新しく追加されたコントロールの新しいビルドには欠点があるため、リリースしたくありません。だから私はアドオン/プラグインのようなアーキテクチャを考えていました。アドオン/プラグインを個別にリリースするだけで、デザイナー内にインストールしてコントロールを取得できます。

現在、コントロール、動作、スタイルなどを指定するためのアドオンとしてxmlファイルを使用しています。各xml（アドオン）は単一のコントロールを表します。しかし、すべてのプラグインを読み取るための汎用パーサーを作成する必要があるため、これを実装するのは非常に難しいと感じています。

代わりに、アドオンごとにdllをリリースして、コントロールの動作/外観を定義し、メインエンジンを介して動的にロードするコードを記述するためのより多くのコントロールを提供できますか？もしそうなら、どうすればdllをチェックしてアプリケーションに動的にロードできますか？

4

3 に答える 3

12

ManagedExtensibilityFrameworkを確認することをお勧めします。これはおそらくあなたの問題のほとんどとそれ以上を解決するでしょうが、いくつかの新しい技術を学ぶ必要があります...

System.Addinmathieuが示唆しているように、名前空間も必ず調べてください。

独自のルートで行きたい場合は、次のアプローチをお勧めします。

  • メインアプリケーションのアドオンのインターフェース
  • そのインターフェイスをアドオンdllに実装する
  • 実行時にdllをロードしますAssembly.Load
    • アドオンアセンブリを別のAppDomainにロードすることを検討することをお勧めします
于 2011-05-25T06:35:17.990 に答える
4

System.Addin名前空間は本当にニーズに合っているので、確認する必要があります。アドインが開発されたら、それをフォルダーにドロップするだけで、（実行時に）アプリケーションで使用できるようになります。

比較のためにこの質問を参照してください：MEFとMAFのどちらを選択するか（System.AddIn）

于 2011-05-25T06:51:05.037 に答える
1

上記のMEFまたはSystem.Addinsルートは、これを実行するための最も効率的な方法である可能性があります。私は、代替案についていくつかのことを言うためにパイプでつなぐだけです。

私はこの種のソリューションを何度も「手作業で」行ってきましたが、最初からやるやむを得ない理由がない限り、既存のアドインフレームワークを使用する方がよいと思います。しかし、そうするつもりなら、Castleや（ここに好みのDIコンテナを挿入してください）のような依存性注入コンテナがいくつかのメカニズムの処理に役立つことがわかりました。

また、実行しようとしていることの種類によっては、マクロ言語を埋め込むアプローチが役立つ可能性があります。IronPythonは簡単に埋め込むことができます。そして、Ayendeは、この種のことやその他多くのことを行うことについて、Booで非常に興味深い本DSLを書きました。

于 2011-05-25T07:00:58.033 に答える