.netFrameworkでMAFを使用してアプリケーションを拡張しています。パイプラインと必要なフォルダー構造を実装しましたが、1つのdllにアドインを実装すると正常に機能します。
1つのdllがコントラクトを実装し、サポートするdllが内部ロジックを実行する複雑なアドインがある場合。
このアドインプロジェクトをビルドすると、メインdllとサポートdllがアドインフォルダーにコピーされ、その時点でフレームワークはそのフォルダーからトークンを見つけることができません。
.netFrameworkでMAFを使用してアプリケーションを拡張しています。パイプラインと必要なフォルダー構造を実装しましたが、1つのdllにアドインを実装すると正常に機能します。
1つのdllがコントラクトを実装し、サポートするdllが内部ロジックを実行する複雑なアドインがある場合。
このアドインプロジェクトをビルドすると、メインdllとサポートdllがアドインフォルダーにコピーされ、その時点でフレームワークはそのフォルダーからトークンを見つけることができません。
パイプライン ドメインはパイプライン フォルダー内から外部依存関係を解決できないため、サポート アセンブリを GAC に配置する必要があります。System.AddIn.Contract の一部のインターフェイスは、説明したようなシナリオ (IServiceProvider および IProfferServiceContract) を対象としているように見えますが、それらの使用方法に関する Microsoft の例はありません。
過去 2 年間、Microsoft が MAF について完全に沈黙していたことは本当に残念です。複雑な実世界の例がないことは、それを使用する複雑さを考えると大きな障害です。沈黙は耳をつんざくようなものです...