.NET Framework アドイン モデルを十分に理解していることが必要です。詳細については、「アドインの概要」を参照してください。

このトピックでは、WPF が .NET Framework アドイン モデルを強化するしくみを説明するために、以下のサンプルを使用します。

• 「UI を返すアドインのサンプル」については、このトピックの「ユーザー インターフェイスを返すアドイン」で説明しています。

• 「アドインが UI である場合のサンプル」については、このトピックの「ユーザー インターフェイスであるアドイン」で説明しています。

• 「複数の UI を持つアドインのサンプル」については、このトピックの「複数の UI を返すアドイン」で説明しています。

• 「XBAP をホスト アプリケーションとして使用するアドインのサンプル」については、このトピックの「アドインと XAML ブラウザ アプリケーション」で説明しています。

新しい機能を追加するためにアプリケーションを再コンパイルして再配置する手間を省くことを目的として、アプリケーションは機能拡張メカニズムを実装し、開発者 (開発元、サード パーティのいずれも) が元のアプリケーションに統合される別のアプリケーションを作成できるようにしています。こうした拡張機能をサポートする方法としては、アドイン ("アドオン"、"プラグイン" などとも呼ばれる) の使用が最も一般的です。アドインによる機能拡張を実行する実際のアプリケーションとして、次のようなものが挙げられます。

• Internet Explorer のアドオン。

• Windows Media Player のプラグイン。

• Visual Studio のアドイン。

たとえば、Windows Media Player のアドイン モデルにおいて、サード パーティの開発者は、Windows Media Player の機能をさまざまな形で拡張する "プラグイン" を実装できます。たとえば、Windows Media Player でネイティブ サポートされていないメディア形式 (DVD、MP3 など) のデコーダおよびエンコーダ、オーディオ エフェクト、スキンなどを作成できます。各アドイン モデルは、アプリケーション固有の機能を組み込むために構築されますが、どのアドイン モデルにも共通するエンティティや動作がいくつかあります。

典型的な機能拡張ソリューションの主な 3 つのエンティティは、コントラクト、アドイン、およびホスト アプリケーションです。コントラクトは、次の 2 つの方法で、アドインとホスト アプリケーションとの統合方法を定義します。

• アドインはホスト アプリケーションによって実装される機能と一体化します。

• ホスト アプリケーションはアドインが一体化するための機能を公開します。

アドインを使用できるようにするためには、ホスト アプリケーションが実行時にアドインを検索して読み込む必要があります。したがって、アドインをサポートするアプリケーションには次の機能が必要です。

• 探索 : ホスト アプリケーションによってサポートされるコントラクトに準拠しているアドインを検索します。

• アクティブ化 : アドインを読み込んで実行し、アドインとの通信を確立します。

• 分離 : アプリケーション ドメインまたはアプリケーション プロセスを使用することで分離境界を確立し、アドインの使用に伴うセキュリティおよび実行に関する潜在的な問題からアプリケーションを保護します。

• 通信 : アドインとホスト アプリケーションが分離の境界を越えて通信し、メソッドを呼び出したりデータを渡したりできるようにします。

• 有効期限管理 : アプリケーション ドメインおよびアプリケーション プロセスの読み込み、およびアンロードをクリーンで予測可能な方法で行います (「アプリケーション ドメインの概要」を参照)。

• バージョン管理 : ホスト アプリケーションとアドインのどちらかに、新バージョンが作成された後も引き続き通信できるようにします。

このことからわかるように、堅牢なアドイン モデルの開発は簡単なことではありません。そのため、.NET Framework にはアドイン モデルの構築に必要なインフラストラクチャが用意されています。

メモ :
アドインの詳細については、「アドインの概要」を参照してください。

.NET Framework アドイン モデルは、System.AddIn 名前空間にあり、アドイン機能拡張の開発を単純化するために設計された型のセットが用意されています。.NET Framework アドイン モデルの基本単位はコントラクトです。コントラクトは、ホスト アプリケーションとアドイン間の通信を定義します。コントラクトのホスト アプリケーション固有のビューを使用して、コントラクトはホスト アプリケーションに公開されます。同様に、コントラクトのアドイン固有のビューがアドインに公開されます。アダプタは、ホスト アプリケーションとアドインが、コントラクトの対応するビュー間で通信するために使用されます。コントラクト、ビュー、およびアダプタはセグメントと見なされ、関連セグメントのセットがパイプラインを構成します。.NET Framework アドイン モデルはパイプラインを基盤とし、それを基に探索、アクティブ化、セキュリティ分離、実行分離 (アプリケーションのドメインとプロセスを両方使用)、通信、有効期間管理、およびバージョン管理をサポートします。

このサポート全体を使用して、開発者はホスト アプリケーションの機能を統合するアドインを開発できます。ただし、一部のシナリオでは、アドインが提供する UI をホスト アプリケーションで表示する必要が生じます。.NET Framework の各プレゼンテーション テクノロジには UI 実装の独自のモデルがあるため、.NET Framework アドイン モデルは特定のプレゼンテーション テクノロジをサポートしません。その代わり、WPF では .NET Framework アドイン モデルをアドインの UI サポートという形で機能拡張します。

WPF を .NET Framework アドイン モデルと併用することで、ホスト アプリケーションでアドインの UI を表示する必要があるさまざまなシナリオに対応できます。特に、WPF によるこれらのシナリオの対応には、次の 2 つのプログラミング モデルが使用されます。

1. アドインが UI を返す。アドインが、コントラクトの定義に従って、メソッド呼び出しを介してホスト アプリケーションに UI を返します。このシナリオは、次の場合に使用されます。

   • アドインが返す UI の外観が、動的に生成されるレポートなど、実行時にしか存在しないデータまたは条件に依存している。

   • アドインが提供するサービスの UI が、そのアドインを使用できるホスト アプリケーションの UI と違っている。

   • アドインは主にホスト アプリケーション向けのサービスを実行し、UI を使用してホスト アプリケーションにステータスをレポートする。

2. アドインが UI である。アドインが、コントラクトの定義に従う UI です。このシナリオは、次の場合に使用されます。

   • アドインは表示以外のサービス (アドバタイズメントなど) を提供しない。

   • アドインが提供するサービスの UI は、そのアドインを使用できるすべてのホスト アプリケーションで共通である (電卓、カラー ピッカーなど)。

これらのシナリオでは、UI オブジェクトをホスト アプリケーション ドメインとアドイン アプリケーション ドメインとの間で受け渡しできる必要があります。.NET Framework アドイン モデルは、アプリケーション ドメイン間の通信においてリモート処理に依存しているため、それらの間で受け渡しされるオブジェクトはリモート処理可能である必要があります。

リモート処理可能なオブジェクトとは、次の 1 つ以上に該当するクラスのインスタンスです。

• MarshalByRefObject クラスから派生している。

• ISerializable インターフェイスを実装している。

• SerializableAttribute 属性が適用されている。

メモ :
リモート処理可能な .NET Framework オブジェクトの作成の詳細については、「オブジェクトをリモート処理可能にする」を参照してください。リモート処理の概要については、「.NET Framework リモート処理の概要」を参照してください。

WPFUI の型はリモート処理可能ではありません。この問題を解決するため、WPF は .NET Framework アドイン モデルを拡張して、アドインによって作成される WPFUI をホスト アプリケーションで表示できるようにします。これは WPF によって、INativeHandleContract インターフェイスと、FrameworkElementAdapters クラスの 2 つの静的メソッド ContractToViewAdapter および ViewToContractAdapter という 2 つの方法でサポートされています。大まかに、これらの型およびメソッドは次のように使用されます。

1. WPF では、アドインが提供する UI が、図形、コントロール、ユーザー コントロール、レイアウト パネル、ページなど、FrameworkElement から直接または間接的に派生したクラスである必要があります。

2. UI がアドインとホスト アプリケーションとの間で受け渡しされることをコントラクトで宣言する場合、必ず INativeHandleContract として宣言する必要があります (FrameworkElement ではない)。INativeHandleContract はアドイン UI のリモート処理可能な表現で、分離の境界を越えて受け渡しできます。

3. アドインのアプリケーション ドメインから渡される前に、FrameworkElement は、ViewToContractAdapter 呼び出しによって、INativeHandleContract としてパッケージ化されます。

4. ホスト アプリケーションのアプリケーション ドメインに渡された後、INativeHandleContract は、ContractToViewAdapter 呼び出しによって、FrameworkElement として再パッケージ化する必要があります。

INativeHandleContract、ContractToViewAdapter、および ViewToContractAdapter の使用形態は、個々のシナリオによって異なります。以降では、各プログラミング モデルについて詳しく説明していきます。

アドインが UI をホスト アプリケーションに返すようにするには、次のことが必要です。

1. ホスト アプリケーション、アドイン、およびパイプラインが、.NET Framework の「アドインおよび拡張機能」の説明に従って作成されている必要があります。

2. コントラクトに IContract を実装することが必要です。また、UI を返すようにするため、戻り値が INativeHandleContract 型であるメソッドをコントラクトで宣言する必要があります。

3. アドインとホスト アプリケーションとの間で受け渡される UI は、直接または間接的に、FrameworkElement から派生している必要があります。

4. アドインが返す UI は、分離境界を越える前に、FrameworkElement から INativeHandleContract に変換される必要があります。

5. 返される UI は、分離境界を越えた後に、INativeHandleContract から FrameworkElement に変換される必要があります。

6. ホスト アプリケーションは、返された FrameworkElement を表示します。

UI を返すアドインを実装する方法の例については、「方法 : UI を返すアドインを作成する」を参照してください。サンプル全体については、「UI を返すアドインのサンプル」を参照してください。

アドインが UI である場合、次のことが必要です。

1. ホスト アプリケーション、アドイン、およびパイプラインが、.NET Framework の「アドインおよび拡張機能」の説明に従って作成されている必要があります。

2. アドインのコントラクト インターフェイスに INativeHandleContract を実装する必要があります。

3. ホスト アプリケーションに渡されるアドインが、直接または間接的に、FrameworkElement から派生している必要があります。

4. アドインは、分離境界を越える前に FrameworkElement から INativeHandleContract に変換される必要があります。

5. アドインは、分離境界を越えた後に INativeHandleContract から FrameworkElement に変換される必要があります。

6. ホスト アプリケーションは、返された FrameworkElement を表示します。

UI を返すアドインを実装する方法の例については、「方法 : UI を返すアドインを作成する」を参照してください。サンプル全体については、「アドインが UI である場合のサンプル」を参照してください。

アドインが提供する複数の UI をホスト アプリケーションが表示するケースはよくあります。たとえば、UI であるアドインが、ホスト アプリケーションにステータス情報も UI として提供するとします。このようなアドインは、ユーザー インターフェイスを返すアドインのモデルとユーザー インターフェイスであるアドインのモデルの両方の手法を組み合わせることで実装できます。

この手法のサンプル全体については、「複数の UI を持つアドインのサンプル」を参照してください。

ここまでの例では、ホスト アプリケーションはスタンドアロン アプリケーションとしてインストールされています。XAML ブラウザ アプリケーション (XBAP) はアドインをホストすることもできますが、そのためには次に示すビルドと実装の要件を満たす必要があります。

• パイプライン (フォルダとアセンブリ) とアドイン アセンブリを、クライアント コンピュータの ClickOnce アプリケーション キャッシュの、XBAP と同じフォルダにダウンロードするよう、XBAP アプリケーション マニフェストを構成する必要があります。

• アドインを探索して読み込む XBAP コードで、XBAP の ClickOnce アプリケーション キャッシュを、パイプラインとアドインの場所として使用する必要があります。

• XBAP は、アドインが起点サイトにある圧縮しないファイルを参照する場合、アドインを特別なセキュリティ コンテキストの下で読み込む必要があります。XBAP によってホストされる場合、アドインが参照できるのは、ホスト アプリケーションの起点サイトにある圧縮しないファイルのみです。

これらのタスクについて、次のサブセクションで詳しく説明します。

メモ :
アドインをホストする XBAP の完全な実装については、「XBAP をホスト アプリケーションとして使用するアドインのサンプル」を参照してください。

ClickOnce 配置のためのパイプラインとアドインの構成

アプリケーション ベースからのパイプラインとアドインの使用

ホストの起点サイトへのアクセス

これまで見てきたように、WPF を使用することによって、.NET Framework アドインで、(FrameworkElement から直接または間接的に派生した) UI を、INativeHandleContract、ViewToContractAdapter、および ContractToViewAdapter を使用して実装できます。その結果、ホスト アプリケーションに FrameworkElement が返され、ホスト アプリケーションの UI で表示されます。

簡単な UI アドイン シナリオでは、開発者に必要な詳細はこれだけです。より複雑なシナリオ、特にレイアウト、リソース、データ バインディングなど、追加 WPF サービスの活用を想定したシナリオでは、その利点と制約を把握するために UI をサポートする .NET Framework アドイン モデルが、WPF で拡張されるしくみについて詳しい知識が必要です。

基本的に、WPF は UI をアドインからホスト アプリケーションに渡しません。その代わり、WPF は UI の Win32 ウィンドウ ハンドルを WPF 相互運用性を使用して渡します。つまり、アドインの UI がホスト アプリケーションに渡されると、次の処理が行われます。

• アドイン側で、WPF は、ホスト アプリケーションによって表示される UI のウィンドウ ハンドルを取得します。このウィンドウ ハンドルは、HwndSource から派生し、INativeHandleContract を実装する内部 WPF クラスによってカプセル化されます。このクラスのインスタンスは、ViewToContractAdapter によって返され、アドインのアプリケーション ドメインからホスト アプリケーションのアプリケーション ドメインにマーシャリングされます。

• ホスト アプリケーション側では、WPF は HwndSource を、HwndHost から派生し、INativeHandleContract を使用する内部 WPF クラスとして、再パッケージ化します。このクラスのインスタンスは、ContractToViewAdapter によってホスト アプリケーションに返されます。

HwndHost は、ウィンドウ ハンドルによって特定される UI を WPFUI で表示するために存在します。詳細については、「WPF と Win32 の相互運用性に関する概要」を参照してください。

まとめると、INativeHandleContract、ViewToContractAdapter、および ContractToViewAdapter は、WPFUI のウィンドウ ハンドルを、アドインからホスト アプリケーションに渡すために存在します。渡されると、HwndHost によってカプセル化され、ホスト アプリケーションの UI を表示します。

メモ :
ホスト アプリケーションは HwndHost を取得するので、ホスト アプリケーションは ContractToViewAdapter から返されるオブジェクトを、アドインによって実装された型 (UserControl など) に変換できません。

その特質上、HwndHost には、ホスト アプリケーションの使用に影響する制約があります。ただし、WPF は、HwndHost をアドイン シナリオ用の一部の機能で拡張します。その利点と制約について以下に説明します。

WPF アドイン UI は、HwndHost から派生する内部クラスを使用してホスト アプリケーションで表示されるため、そのような UI は、レイアウト、レンダリング、データ バインディング、スタイル、テンプレート、リソースなどの WPFUI サービスに関して、HwndHost の機能の制約を受けます。ただし、WPF は、その内部 HwndHost サブクラスを、次のような追加機能で強化します。

• ホスト アプリケーションの UI とアドインの UI との間を Tab キーで移動できます。"アドインが UI である" プログラミング モデルでは、アドインが完全に信頼されているか部分的に信頼されているかに関係なく、アドイン側のアダプタが QueryContract をオーバーライドして、Tab キーによる移動処理を有効にする必要があります。

• ホスト アプリケーション UI で表示されるアドイン UI のアクセシビリティ要件を順守します。

• アプリケーション ドメインが複数あるシナリオで WPF アプリケーションが安全に実行されます。

• アドインがセキュリティ分離を使用して実行されている場合 (部分的に信頼されているセキュリティ サンドボックス)、アドイン UI ウィンドウ ハンドルへの不正アクセスを回避します。ViewToContractAdapter を呼び出すことでこのセキュリティが保証されます。

  • "アドインが UI を返す" プログラミング モデルで、アドイン UI のウィンドウ ハンドルを分離境界を越えて渡す唯一の方法は、ViewToContractAdapter を呼び出すことです。

  • "アドインが UI である" プログラミング モデルでは、アドイン側のアダプタで QueryContract をオーバーライドして ViewToContractAdapter を呼び出すこと (前の例に従って) が、アドイン側のアダプタの QueryContract 実装をホスト側のアダプタから呼び出すことに相当する処理として必要です。

• アプリケーション ドメインの実行を何重にも保護します。アプリケーション ドメインの制約に起因して、アドイン アプリケーション ドメインでスローされた未処理の例外は、分離境界が存在していても、アプリケーション全体のクラッシュにつながります。ただし、WPF アドイン モデルおよび .NET Framework アドイン モデルは、この問題を回避し、アプリケーションの安定性を向上させる簡単な手段を提供します。UI を表示する WPF アドインは、ホスト アプリケーションが WPF アプリケーションである場合に、アプリケーション ドメインが実行されているスレッドの Dispatcher を作成します。WPF アドインの Dispatcher の UnhandledException イベントを処理することで、アプリケーション ドメインで発生した未処理の例外をすべて検出できます。Dispatcher は、CurrentDispatcher プロパティから取得できます。

WPF は、HwndSource、HwndHost、およびウィンドウ ハンドルによる既定の動作に利点をもたらしますが、ホスト アプリケーションで表示されるアドイン UI に対する制約もあります。

• ホスト アプリケーションで表示されるアドイン UI では、ホスト アプリケーションのクリッピング動作が考慮されません。

• 相互運用性シナリオの空域の概念もアドインに適用されます (「WPF 相互運用 : "空域" およびウィンドウ領域の概要」を参照)。

• リソースの継承、データ バインディング、コマンド実行など、ホスト アプリケーションの UI サービスは、アドイン UI で自動的に使用可能化されないためです。このサービスをアドインに提供するには、パイプラインを更新する必要があります。

• アドイン UI に回転、拡大縮小、傾斜などの変換は適用できません (「変換の概要」を参照)。

• System.Drawing 名前空間の描画操作によって描画されるアドイン UI 内のコンテンツに、アルファ ブレンド効果を含めることができます。ただし、それを含むアドイン UI とホスト アプリケーション UI のいずれも、完全に不透明である必要があります。言い換えると、どちらについても Opacity プロパティが 1 に設定されている必要があります。

• アドイン UI を含むホスト アプリケーションのウィンドウの AllowsTransparency プロパティが true の場合、アドインは非表示になります。このことは、アドイン UI が完全に不透明 (Opacity プロパティの値が 1) の場合にも該当します。

• アドイン UI は、同じトップレベル ウィンドウ内の他の WPF 要素より前面に表示する必要があります。

• アドインの UI には、VisualBrush を使用して描画できる部分はありません。その代わり、アドインは生成された UI のスナップショットを取り、コントラクトで定義されているメソッドを使用してホスト アプリケーションに渡すことができるビットマップを作成できます。

• メディア ファイルをアドイン UI 内の MediaElement で再生することはできません。

• ホスト アプリケーションがアドイン UI 用に生成されたマウス イベントを発生させたり、受け取ったりすることはなく、ホスト アプリケーション UI の IsMouseOver プロパティの値は false に設定されます。

• アドイン UI 内のコントロール間を、フォーカスが移動しても、GotFocus イベントおよび LostFocus イベントをホスト アプリケーションで受け取ったり、発生したりすることはありません。

• アドイン UI を含むホスト アプリケーション部分は、印刷時には白く出力されます。

• アドイン UI によって作成されたすべてのディスパッチャ (「Dispatcher」を参照) は、ホスト アプリケーションが実行を継続する場合、オーナー アドインがアンロードされる前に手動でシャットダウンする必要があります。コントラクトは、アドインがアンロードされる前にホスト アプリケーションがアドインにシグナルを送信するためのメソッドを実装でき、それによりアドイン UI がそのディスパッチャをシャットダウンできます。

• アドイン UI が InkCanvas である場合、または InkCanvas を含んでいる場合、そのアドインをアンロードすることはできません。

既定では、複数のアプリケーション ドメインが使用されていると、各アプリケーションで必要とされているさまざまな .NET Framework アセンブリがすべてそのアプリケーションのドメインに読み込まれます。その結果、新しいアプリケーション ドメインを作成してその中でアプリケーションを起動するために必要な時間がパフォーマンスに影響します。ただし、.NET Framework には、アプリケーションに必要なアセンブリが既に読み込まれている場合に、それをアプリケーション ドメイン間で共有するよう指示することで起動時間を短縮する手段が用意されています。これを行うには、LoaderOptimizationAttribute 属性を使用します。これを、エントリ ポイント メソッド (Main) に適用する必要があります。この場合、アプリケーション定義を実装するコードのみを使用する必要があります (「アプリケーション管理の概要」を参照)。

以下のサンプルでは、ここまでに説明した LoaderOptimizationAttribute の使用方法を示します。

• UI を返すアドインのサンプル.

• アドインが UI である場合のサンプル.

• 複数の UI を持つアドインのサンプル.

処理手順

概念

参照

その他の技術情報