プロセス間通信 (IPC)Interprocess communication (IPC)

このトピックでは、ユニバーサル Windows プラットフォーム (UWP) アプリケーションと Win32 アプリケーションの間でプロセス間通信 (IPC) を実行するさまざまな方法について説明します。This topic explains various ways to perform interprocess communication (IPC) between Universal Windows Platform (UWP) applications and Win32 applications.

App ServicesApp services

App services を使用すると、アプリケーションは、プリミティブ (Valueset) のプロパティバッグを受け取って返すサービスをバックグラウンドで公開できます。App services enable applications to expose services that accept and return property bags of primitives (ValueSet) in the background. リッチオブジェクトは、 シリアル化されている場合は渡すことができます。Rich objects can be passed if they're serialized.

App services は、バックグラウンドタスクとして、またはフォアグラウンドアプリケーション内のプロセスでアウトプロセスで実行できます。App services can run either out of process as a background task, or in process within the foreground application.

App services は、ほぼリアルタイムの待機時間を必要としない、少量のデータを共有する場合に最適です。App services are best used for sharing small amounts of data where near real-time latency isn't required.

COM (COM)COM

COM は、相互作用および通信を可能にするバイナリソフトウェアコンポーネントを作成するための分散オブジェクト指向システムです。COM is a distributed object-oriented system for creating binary software components that can interact and communicate. 開発者は、COM を使用して、アプリケーションの再利用可能なソフトウェアコンポーネントとオートメーションレイヤーを作成します。As a developer, you use COM to create reusable software components and automation layers for an application. COM コンポーネントは、プロセス内またはプロセス外に配置でき、 クライアントとサーバー のモデルを介して通信できます。COM components can be in process or out of process, and they can communicate via a client and server model. アウトプロセス COM サーバーは、 オブジェクト間通信の手段として長期間使用されています。Out-of-process COM servers have long been used as a means for inter-object communication.

Runfulltrust機能を備えたパッケージアプリケーションでは、パッケージマニフェストを使用して IPC 用のアウトプロセス COM サーバーを登録できます。Packaged applications with the runFullTrust capability can register out-of-process COM servers for IPC via the package manifest. これは、 パッケージ COMと呼ばれます。This is known as Packaged COM.

ファイルシステムFilesystem

BroadFileSystemAccessBroadFileSystemAccess

パッケージ化されたアプリケーションは、 broadFileSystemAccess 制限機能を宣言することで、広範なファイルシステムを使用して IPC を実行できます。Packaged applications can perform IPC using the broad filesystem by declaring the broadFileSystemAccess restricted capability. この機能により、 Windows の Storage Api と xxx Fromapp Win32 api が広範なファイルシステムにアクセスできるようになります。This capability grants Windows.Storage APIs and xxxFromApp Win32 APIs access to the broad filesystem.

既定では、パッケージアプリケーションのファイルシステムを介した IPC は、このセクションで説明する他のメカニズムに限定されます。By default, IPC via the filesystem for packaged applications is restricted to the other mechanisms described in this section.

PublisherCacheFolderPublisherCacheFolder

PublisherCacheFolderを使用すると、パッケージアプリケーションでマニフェスト内のフォルダーを宣言し、同じ発行元によって他のパッケージと共有できるようになります。The PublisherCacheFolder enables packaged applications to declare folders in their manifest that can be shared with other packages by the same publisher.

共有ストレージフォルダーには、次の要件と制限があります。The shared storage folder has the following requirements and restrictions:

  • 共有ストレージフォルダー内のデータは、バックアップまたはローミングされません。Data in the shared storage folder is not backed up or roamed.
  • ユーザーは、共有ストレージフォルダーの内容を消去できます。The user can clear the contents of the shared storage folder.
  • 共有ストレージフォルダーを使用して、さまざまなパブリッシャーのアプリケーション間でデータを共有することはできません。You can't use the shared storage folder to share data among applications from different publishers.
  • 共有ストレージフォルダーを使用して、異なるユーザー間でデータを共有することはできません。You can't use the shared storage folder to share data among different users.
  • 共有ストレージフォルダーには、バージョン管理がありません。The shared storage folder doesn't have version management.

複数のアプリケーションを発行し、それらの間でデータを共有するための簡単なメカニズムを探している場合、PublisherCacheFolder は単純なファイルシステムベースのオプションです。If you publish multiple applications and you're looking for a simple mechanism to share data between them, then the PublisherCacheFolder is a simple filesystem-based option.

SharedAccessStorageManagerSharedAccessStorageManager

Sharedaccessstoragemanager は、アプリサービス、プロトコルのアクティブ化 (たとえば Launchurifor等 async) などと共に使用して、トークンを介して storagefiles を共有します。SharedAccessStorageManager is used in conjunction with App services, protocol activations (for example, LaunchUriForResultsAsync), etc., to share StorageFiles via tokens.

FullTrustProcessLauncherFullTrustProcessLauncher

Runfulltrust機能を使用すると、パッケージアプリケーションは同じパッケージ内で完全信頼プロセスを起動できます。With the runFullTrust capability, packaged applications can launch full trust processes within the same package.

パッケージの制限が負担になるシナリオや、IPC オプションがない場合は、アプリケーションで完全信頼プロセスをプロキシとして使用してシステムとのインターフェイスを設定し、App services またはその他の適切なサポートされている IPC メカニズムを使用して完全信頼プロセス自体を IPC することができます。For scenarios where package restrictions are a burden, or IPC options are lacking, an application could use a full trust process as a proxy to interface with the system, and then IPC with the full trust process itself via App services or some other well supported IPC mechanism.

LaunchUriForResultsAsyncLaunchUriForResultsAsync

Launchuriforresults asyncは、 protocolforresultsアクティブ化コントラクトを実装する他のパッケージアプリケーションとの単純な (valueset) データ交換に使用されます。LaunchUriForResultsAsync is used for simple (ValueSet) data exchange with other packaged applications that implement the ProtocolForResults activation contract. 通常はバックグラウンドで実行される App services とは異なり、ターゲットアプリケーションはフォアグラウンドで起動されます。Unlike App services, which typically run in the background, the target application is launched in the foreground.

ファイルは、 Storagestorageaccessmanager トークンを valueset 経由でアプリケーションに渡すことによって共有できます。Files can be shared by passing SharedStorageAccessManager tokens to the application via the ValueSet.

ループバックLoopback

ループバックは、localhost (ループバックアドレス) でリッスンしているネットワークサーバーと通信するプロセスです。Loopback is the process of communicating with a network server listening on localhost (the loopback address).

セキュリティとネットワークの分離を維持するために、IPC のループバック接続は、パッケージアプリケーションでは既定でブロックされます。To maintain security and network isolation, loopback connections for IPC are blocked by default for packaged applications. 信頼されたパッケージアプリケーション間のループバック接続は、 機能マニフェストのプロパティを使用して有効にすることができます。You can enable loopback connections among trusted packaged application using capabilities and manifest properties.

  • ループバック接続に参加するすべてのパッケージアプリケーションは、 privateNetworkClientServer パッケージマニフェストで機能を宣言する必要があります。All packaged applications participating in loopback connections will need to declare the privateNetworkClientServer capability in their package manifests.
  • パッケージマニフェスト内で LoopbackAccessRules を宣言することで、2つのパッケージ化されたアプリケーションがループバック経由で通信できるようになります。Two packaged applications can communicate via loopback by declaring LoopbackAccessRules within their package manifests.
    • 各アプリケーションは、 LoopbackAccessRules内の他のアプリケーションを一覧表示する必要があります。Each application must list the other in its LoopbackAccessRules. クライアントはサーバーに対して "out" 規則を宣言し、サーバーはサポートされているクライアントの "in" 規則を宣言します。The client declares an "out" Rule for the server, and the server declares "in" Rules for its supported clients.

注意

これらの規則でアプリケーションを識別するために必要なパッケージファミリ名は、開発時に Visual Studio のパッケージマニフェストエディターを使用するか、Microsoft Store で公開されたアプリケーションの パートナーセンター を通じて、または既にインストールされているアプリケーションの get-appxpackage PowerShell コマンドを使用して見つけることができます。The package family name required to identify an application in these Rules can be found via the package manifest editor in Visual Studio during development time, via Partner Center for applications published through the Microsoft Store, or via the Get-AppxPackage PowerShell command for applications that are already installed.

パッケージ化されていないアプリケーションやサービスには、パッケージ id がないため、 LoopbackAccessRulesで宣言することはできません。Unpackaged applications and services don't have package identity, so they can't be declared in LoopbackAccessRules. パッケージ化されたアプリケーションを CheckNetIsolation.exe経由でアンパッケージされたアプリケーションやサービスと共にループバック経由で接続するように構成できますが、これが可能なのは、コンピューターへのローカルアクセスを持つサイドロードまたはデバッグのシナリオと、管理者特権がある場合のみです。You can configure a packaged application to connect via loopback with unpackaged applications and services via CheckNetIsolation.exe, however this is only possible for sideload or debugging scenarios where you have local access to the machine, and you have administrator privileges.

  • ループバック接続に参加するすべてのパッケージアプリケーションは、 privateNetworkClientServer パッケージマニフェストで機能を宣言する必要があります。All packaged applications participating in loopback connections need to declare the privateNetworkClientServer capability in their package manifests.
  • パッケージ化されたアプリケーションが、パッケージ化されていないアプリケーションまたはサービスに接続している場合は、を実行して、 CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> パッケージアプリケーションのループバックの除外対象を追加します。If a packaged application is connecting to an unpackaged application or service, run CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> to add a loopback exemption for the packaged application.
  • パッケージ化されていないアプリケーションまたはサービスがパッケージアプリケーションに接続している場合は、を実行し CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> て、パッケージ化されたアプリケーションが受信ループバック接続を受信できるようにします。If an unpackaged application or service is connecting to a packaged application, run CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> to enable the packaged application to receive inbound loopback connections.
    • CheckNetIsolation.exe は、パッケージアプリケーションが接続をリッスンしている間、継続的に実行されている必要があります。CheckNetIsolation.exe must be running continuously while the packaged application is listening for connections.
    • この -is フラグは、Windows 10 バージョン1607で導入されました (10.0;ビルド 14393)。The -is flag was introduced in Windows 10, version 1607 (10.0; Build 14393).

注意

CheckNetIsolation.exeのフラグに必要なパッケージファミリ名は、 -n 開発時に Visual Studio のパッケージマニフェストエディターを使用するか、Microsoft Store を通じて発行されたアプリケーションのパートナーセンターを通じて、または既にインストールされているアプリケーションのget-appxpackage PowerShell コマンドを使用して見つけることができます。 CheckNetIsolation.exeThe package family name required for the -n flag of CheckNetIsolation.exe can be found via the package manifest editor in Visual Studio during development time, via Partner Center for applications published through the Microsoft Store, or via the Get-AppxPackage PowerShell command for applications that are already installed.

CheckNetIsolation.exe は、ネットワークの 分離に関する問題をデバッグする場合にも役立ちます。CheckNetIsolation.exe is also useful for debugging network isolation issues.

パイプPipes

パイプを使用する と、パイプサーバーと1つ以上のパイプクライアントとの間で簡単な通信を行うことができます。Pipes enable simple communication between a pipe server and one or more pipe clients.

匿名パイプ名前付きパイプ は、次の制約でサポートされています。Anonymous pipes and named pipes are supported with the following constraints:

  • 既定では、パッケージアプリケーションの名前付きパイプは、プロセスが完全に信頼されていない限り、同じパッケージ内のプロセス間でのみサポートされます。By default, named pipes in packaged applications are supported only between processes within the same package, unless a process is full trust.
  • 名前付きパイプは、 名前付きオブジェクトを共有するためのガイドラインに従って、パッケージ間で共有できます。Named pipes can be shared across packages following the guidelines for sharing named objects.
  • パッケージ化されたアプリケーションの名前付きパイプでは、パイプ名の構文を使用する必要があり \\.\pipe\LOCAL\ ます。Named pipes in packaged applications must use the syntax \\.\pipe\LOCAL\ for the pipe name.

レジストリRegistry

IPC のレジストリの使用は一般に推奨されていませんが、既存のコードではサポートされています。Registry usage for IPC is generally discouraged, but it is supported for existing code. パッケージ化されたアプリケーションは、アクセス許可のあるレジストリキーのみにアクセスできます。Packaged applications can access only registry keys that they have permission to access.

Msix としてパッケージ化 されたデスクトップアプリケーションは、 レジストリの仮想化 を利用して、グローバルレジストリの書き込みが msix パッケージ内のプライベート hive に含まれるようにします。Desktop applications packaged as MSIX leverage registry virtualization such that global registry writes are contained to a private hive within the MSIX package. これにより、グローバルレジストリへの影響を最小限に抑えながらソースコードの互換性を確保し、同じパッケージ内のプロセス間で IPC に使用できます。This enables source code compatibility while minimizing global registry impact, and can be used for IPC between processes in the same package. レジストリを使用する必要がある場合は、このモデルを使用してグローバルレジストリを操作することをお勧めします。If you must use the registry, this model is preferred versus manipulating the global registry.

RPCRPC

パッケージアプリケーションに RPC エンドポイントの Acl と一致する適切な機能がある場合、 rpcを使用して、パッケージ化されたアプリケーションを Win32 RPC エンドポイントに接続することができます。RPC can be used to connect a packaged application to a Win32 RPC endpoint, provided that the packaged application has the correct capabilities to match the ACLs on the RPC endpoint.

カスタム機能を使用すると、Oem および Ihv は 任意の機能を定義し、 それらの機能と共に RPC エンドポイントの ACLを作成して、承認された クライアントアプリケーションにこれらの機能を付与できます。Custom capabilities enable OEMs and IHVs to define arbitrary capabilities, ACL their RPC endpoints with them, and then grant those capabilities to authorized client applications. 完全なサンプルアプリケーションについては、 Customcapability ビリティ のサンプルを参照してください。For a full sample application, see the CustomCapability sample.

RPC エンドポイントは、特定のパッケージアプリケーションを利用して、エンドポイントへのアクセスをそのアプリケーションだけに制限することもできます。カスタム機能の管理オーバーヘッドは必要ありません。RPC endpoints can also be ACLed to specific packaged applications to limit access to the endpoint to just those applications without requiring the management overhead of custom capabilities. DeriveAppContainerSidFromAppContainerName API を使用してパッケージファミリ名から sid を取得し、 customcapability ビリティサンプルに示されているように、sid を使用して RPC エンドポイントに ACL を指定することができます。You can use the DeriveAppContainerSidFromAppContainerName API to derive a SID from a package family name, and then ACL the RPC endpoint with the SID as shown in the CustomCapability sample.

共有メモリShared Memory

ファイルマッピング を使用すると、2つ以上のプロセス間でファイルまたはメモリを共有し、次の制約を設定できます。File mapping can be used to share a file or memory between two or more processes with the following constraints:

  • 既定では、パッケージアプリケーションのファイルマッピングは、プロセスが完全に信頼されていない限り、同じパッケージ内のプロセス間でのみサポートされます。By default, file mappings in packaged applications are supported only between processes within the same package, unless a process is full trust.
  • ファイルマッピングは、 名前付きオブジェクトを共有するためのガイドラインに従って、パッケージ間で共有できます。File mappings can be shared across packages following the guidelines for sharing named objects.

大量のデータを効率的に共有および操作するには、共有メモリを使用することをお勧めします。Shared memory is recommended for efficiently sharing and manipulating large amounts of data.