このトピックでは、ユニバーサル Windows プラットフォーム (UWP) アプリケーションと Win32 アプリケーションの間でプロセス間通信 (IPC) を実行するさまざまな方法について説明します。
アプリ サービス
アプリ サービスを使用すると、アプリケーションは、バックグラウンドでプリミティブ (ValueSet) のプロパティ バッグを受け入れて返すサービスを公開できます。 リッチ オブジェクトは、シリアル化
アプリ サービスは、バックグラウンド タスクとしてプロセス外で、またはフォアグラウンド アプリケーション内プロセス内で実行できます。
アプリ サービスは、ほぼリアルタイムの待機時間が必要ない少量のデータを共有するために最適です。
COM
COM は、対話および通信できるバイナリ ソフトウェア コンポーネントを作成するための分散オブジェクト指向システムです。 開発者は、COM を使用して、アプリケーションの再利用可能なソフトウェア コンポーネントとオートメーション レイヤーを作成します。 COM コンポーネントは、処理中でもプロセス外でも、 クライアントおよびサーバー モデルを介して通信できます。 アウトプロセス COM サーバーは、オブジェクト間通信を
runFullTrust 機能を備えたパッケージ 化されたアプリケーションは、パッケージ マニフェストを使用して IPC のアウトプロセス COM サーバーを登録できます。 これは パッケージ化された COMと呼ばれます。
ファイルシステム
広範囲ファイルシステムアクセス
パッケージ化されたアプリケーションは、 broadFileSystemAccess 制限付き機能を宣言することで、広範なファイルシステムを使用して IPC を実行できます。 この機能により、 Windows.Storage API と xxxFromApp Win32 API に広範なファイルシステムへのアクセスが許可されます。
既定では、パッケージ化されたアプリケーションのファイルシステム経由の IPC は、このセクションで説明する他のメカニズムに制限されます。
パブリッシャーキャッシュフォルダ
PublisherCacheFolder を使用すると、パッケージ化されたアプリケーションは、同じ発行元が他のパッケージと共有できるフォルダーをマニフェストで宣言できます。
共有ストレージ フォルダーには、次の要件と制限があります。
- 共有ストレージ フォルダー内のデータはバックアップもローミングもされません。
- ユーザーは、共有ストレージ フォルダーの内容をクリアできます。
- 共有ストレージ フォルダーを使用して、異なる発行元のアプリケーション間でデータを共有することはできません。
- 共有ストレージ フォルダーを使用して、異なるユーザー間でデータを共有することはできません。
- 共有ストレージ フォルダーにはバージョン管理がありません。
複数のアプリケーションを発行し、それらの間でデータを共有する簡単なメカニズムを探している場合、PublisherCacheFolder は単純なファイルシステム ベースのオプションです。
共有アクセスストレージ管理者
SharedAccessStorageManager は、App Services、プロトコルのアクティブ化 (LaunchUriForResultsAsync など) と組み合わせて使用され、トークンを介して StorageFiles を共有します。
フルトラストプロセスランチャー
パッケージの制限が負担になる、または IPC オプションが不足しているシナリオでは、アプリケーションは完全信頼プロセスをプロキシとして使用してシステムとインターフェイスし、その後、App Services またはその他の適切にサポートされている IPC メカニズムを介して完全信頼プロセス自体を使用する可能性があります。
LaunchUriForResultsAsyncメソッドを使用する
LaunchUriForResultsAsync は、ProtocolForResults アクティブ化コントラクトを実装する他のパッケージ 化されたアプリケーションとの単純な (ValueSet) データ交換に使用されます。 通常バックグラウンドで実行される App Services とは異なり、ターゲット アプリケーションはフォアグラウンドで起動されます。
ファイルは、ValueSet を介して SharedStorageAccessManager トークンをアプリケーションに渡すことによって共有できます。
ループバック
ループバックは、localhost (ループバック アドレス) でリッスンしているネットワーク サーバーと通信するプロセスです。
セキュリティとネットワークの分離を維持するために、パッケージ化されたアプリケーションでは、IPC のループバック接続が既定でブロックされます。 機能とマニフェスト プロパティを使用して、信頼されたパッケージ 化されたアプリケーション間のループバック接続を有効にすることができます。
- ループバック接続に参加しているすべてのパッケージ アプリケーションは、
privateNetworkClientServerで機能を宣言する必要があります。 - パッケージ マニフェスト内で LoopbackAccessRules を宣言することで、2 つのパッケージ 化されたアプリケーションがループバック経由で通信できます。
- 各アプリケーションは、 その LoopbackAccessRules 内のもう一方を一覧表示する必要があります。 クライアントはサーバーの "out" ルールを宣言し、サーバーはサポートされているクライアントに対して "in" ルールを宣言します。
注
これらのルールでアプリケーションを識別するために必要なパッケージ ファミリ名は、開発時に Visual Studio のパッケージ マニフェスト エディター、Microsoft Store を介して発行されたアプリケーションの パートナー センター 、または既にインストールされているアプリケーションの Get-AppxPackage PowerShell コマンドを使用して確認できます。
パッケージ化されていないアプリケーションとサービスにはパッケージ ID がないため、 LoopbackAccessRules で宣言することはできません。 パッケージ化されていないアプリケーションとサービスを CheckNetIsolation.exe経由して ループバック経由で接続するようにパッケージ化されたアプリケーションを構成できますが、これは、コンピューターへのローカル アクセス権があり、管理者特権があるサイドロードまたはデバッグシナリオでのみ可能です。
- ループバック接続に参加しているすべてのパッケージ アプリケーションは、
privateNetworkClientServerで機能を宣言する必要があります。 - パッケージ化されていないアプリケーションがパッケージ化されていないアプリケーションまたはサービスに接続している場合は、
CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME>実行して、パッケージ化されたアプリケーションのループバック除外を追加します。 - パッケージ化されていないアプリケーションまたはサービスがパッケージ化されたアプリケーションに接続している場合は、
CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME>を実行して、パッケージ化されたアプリケーションが受信ループバック接続を受信できるようにします。- CheckNetIsolation.exe は、パッケージ化されたアプリケーションが接続を待機している間、継続的に実行されている必要があります。
-
-isフラグは、Windows 10 バージョン 1607 (10.0; ビルド 14393) で導入されました。
注
-n の フラグに必要なパッケージ ファミリ名は、開発時に Visual Studio のパッケージ マニフェスト エディター、Microsoft Store を介して公開されたアプリケーションのパートナー センター、または既にインストールされているアプリケーションの Get-AppxPackage PowerShell コマンドを使用して見つけることができます。
CheckNetIsolation.exe は、 ネットワーク分離の問題のデバッグにも役立ちます。
パイプ
パイプ を使用すると、パイプ サーバーと 1 つ以上のパイプ クライアント間の簡単な通信が可能になります。
匿名パイプ と 名前付きパイプ は、次の制約でサポートされています。
- 既定では、パッケージ 化されたアプリケーションの名前付きパイプは、プロセスが完全信頼でない限り、同じパッケージ内のプロセス間でのみサポートされます。
- 名前付きパイプは、名前 付きオブジェクトを共有するためのガイドラインに従って、パッケージ間で共有できます。
- 名前付きパイプ (パッケージ化 されたアプリと パッケージ化されていないアプリ) では、パイプ名に構文
\\.\pipe\LOCAL\を使用する必要があります。
レジストリ
IPC のレジストリの使用は一般に推奨されませんが、既存のコードではサポートされています。 パッケージ化されたアプリケーションは、アクセス許可を持つレジストリ キーにのみアクセスできます。
一般に、パッケージ化されたデスクトップ アプリ ( コードからの MSIX パッケージのビルドを参照) では 、グローバル レジストリ の書き込みが MSIX パッケージ内のプライベート ハイブに含まれるようレジストリ仮想化を利用します。 これにより、グローバル レジストリへの影響を最小限に抑えながらソース コードの互換性が実現し、同じパッケージ内のプロセス間の IPC に使用できます。 レジストリを使用する必要がある場合は、グローバル レジストリを操作するより、このモデルをお勧めします。
RPCの
RPC は、パッケージ化されたアプリケーションが RPC エンドポイントの ACL と一致する適切な機能を備える場合に、パッケージ化されたアプリケーションを Win32 RPC エンドポイントに接続するために使用できます。
カスタム機能を使用すると、OEM と IHV は任意の機能定義
RPC エンドポイントは、カスタム機能の管理オーバーヘッドを必要とせずに、特定のパッケージ 化されたアプリケーションに対して ACL を使用して、エンドポイントへのアクセスをそれらのアプリケーションのみに制限することもできます。 DeriveAppContainerSidFromAppContainerName API を使用して、パッケージ ファミリ名から SID を派生させ、次に CustomCapability サンプルに示すように、SID を使用して RPC エンドポイントを ACL できます。
共有メモリ
ファイル マッピング を使用すると、次の制約を持つ 2 つ以上のプロセス間でファイルまたはメモリを共有できます。
- 既定では、パッケージ 化されたアプリケーションのファイル マッピングは、プロセスが完全に信頼されていない限り、同じパッケージ内のプロセス間でのみサポートされます。
- ファイル マッピングは、 名前付きオブジェクトを共有するためのガイドラインに従って、パッケージ間で共有できます。
大量のデータを効率的に共有および操作するには、共有メモリをお勧めします。