Prozessübergreifende Kommunikation (Interprocess Communication, IPC)

In diesem Thema werden verschiedene Möglichkeiten zum Ausführen der Interprozesskommunikation (IPC) zwischen Universellen Windows-Plattform-Anwendungen (UWP) und Win32-Anwendungen erläutert.

App-Dienste

App Services können Anwendungen Dienste verfügbar machen, die Eigenschaftenbehälter von Grundtypen (ValueSet) im Hintergrund akzeptieren und zurückgeben. Rich-Objekte können übergeben werden, wenn sie serialisiert werden.

App Services können entweder „out of process“ als Hintergrundaufgabe oder „in process“ innerhalb der Vordergrundanwendung ausgeführt werden.

App Services werden am besten für die Freigabe kleiner Datenmengen verwendet, bei denen die Latenz in Quasi-Echtzeit nicht erforderlich ist.

COM

COM ist ein verteiltes und objektorientiertes System zum Erstellen von binären Softwarekomponenten, die miteinander interagieren und kommunizieren können. Als Entwickler verwenden Sie COM, um wiederverwendbare Softwarekomponenten und Automatisierungsebenen für eine Anwendung zu erstellen. COM-Komponenten können „in process“ oder „out of process“ sein, und sie können über ein Client- und Servermodell kommunizieren. Out-of-Process-COM-Server werden seit langem als Mittel für die Kommunikation zwischen Objekten verwendet.

Verpackte Anwendungen mit der RunFullTrust-Funktion können out-of-process COM-Server für IPC über das Paketmanifest registrieren. Dies wird als verpacktes COM bezeichnet.

Dateisystem

BroadFileSystemAccess

Verpackte Anwendungen können IPC mithilfe des allgemeinen Dateisystems ausführen, indem sie die eingeschränkte BroadFileSystemAccess-Funktion deklarieren. Diese Funktion gewährt Windows.Storage-APIs und xxxFromApp Win32-APIs Zugriff auf das allgemeine Dateisystem.

Standardmäßig ist IPC über das Dateisystem für verpackte Anwendungen auf die anderen Mechanismen beschränkt, die in diesem Abschnitt beschrieben werden.

PublisherCacheFolder

PublisherCacheFolder ermöglicht verpackten Anwendungen das Deklarieren von Ordnern in ihrem Manifest, die von demselben Herausgeber für andere Pakete freigegeben werden können.

Der freigegebene Speicherordner hat die folgenden Anforderungen und Einschränkungen:

• Daten im freigegebenen Speicherordner werden nicht gesichert oder übertragen.
• Der Benutzer kann den Inhalt des freigegebenen Speicherordners löschen.
• Sie können den freigegebenen Speicherordner nicht zum Freigeben von Daten zwischen Anwendungen von verschiedenen Herausgebern verwenden.
• Sie können den freigegebenen Speicherordner nicht verwenden, um Daten für verschiedene Benutzer freizugeben.
• Der freigegebene Speicherordner verfügt nicht über Versionsverwaltung.

Wenn Sie mehrere Anwendungen veröffentlichen und nach einem einfachen Mechanismus zum Freigeben von Daten zwischen ihnen suchen, ist PublisherCacheFolder eine einfache dateisystembasierte Option.

SharedAccessStorageManager

SharedAccessStorageManager wird in Verbindung mit App Services, Protokollaktivierungen (z. B. LaunchUriForResultsAsync) verwendet, um StorageFiles über Token freizugeben.

FullTrustProcessLauncher

Mit der RunFullTrust-Funktion können verpackte Anwendungen voll vertrauenswürdige Prozesse innerhalb desselben Pakets starten.

Für Szenarien, in denen Paketeinschränkungen eine Belastung darstellen oder IPC-Optionen fehlen, könnte eine Anwendung einen voll vertrauenswürdigen Prozess als Proxy für die Schnittstelle mit dem System verwenden und dann IPC mit dem vollständig vertrauenswürdigen Prozess selbst über App Services oder einen anderen gut unterstützten IPC-Mechanismus verwenden.

LaunchUriForResultsAsync

LaunchUriForResultsAsync wird für den einfachen (ValueSet)-Datenaustausch mit anderen verpackten Anwendungen verwendet, die den ProtocolForResults-Aktivierungsvertrag implementieren. Im Gegensatz zu App Services, die normalerweise im Hintergrund ausgeführt werden, wird die Zielanwendung im Vordergrund gestartet.

Dateien können freigegeben werden, indem SharedStorageAccessManager-Token über das ValueSet an die Anwendung übergeben werden.

Loopback

Loopback ist der Prozess der Kommunikation mit einem Netzwerkserver, der auf Localhost lauscht (die Loopbackadresse).

Um Sicherheit und Netzwerkisolation zu bewahren, werden Loopbackverbindungen für IPC standardmäßig für verpackte Anwendungen blockiert. Sie können Loopbackverbindungen zwischen vertrauenswürdigen verpackten Anwendungen mithilfe von Funktionen und Manifesteigenschaften aktivieren.

• Alle verpackten Anwendungen, die an Loopbackverbindungen teilnehmen, müssen die privateNetworkClientServer-Funktion in ihren Paketmanifesten deklarieren.
• Zwei verpackte Anwendungen können über Loopback kommunizieren, indem LoopbackAccessRules innerhalb ihrer Paketmanifeste deklariert werden.
  • Jede Anwendung muss die andere in ihrer LoopbackAccessRules auflisten. Der Client deklariert eine „Out“-Regel für den Server, und der Server deklariert „In“-Regeln für seine unterstützten Clients.

Hinweis

Der Paketfamilienname, der zum Identifizieren einer Anwendung in diesen Regeln erforderlich ist, finden Sie im Paketmanifest-Editor in Visual Studio während der Entwicklungszeit, über Partner Center für Anwendungen, die über den Microsoft Store veröffentlicht wurden, oder über den PowerShell-Befehl „Get-AppxPackage“, für Anwendungen, die bereits installiert sind.

Entpackte Anwendungen und Dienste besitzen keine Paketidentität, sodass sie nicht in LoopbackAccessRules deklariert werden können. Sie können eine verpackte Anwendung so konfigurieren, dass sie über Loopback mit entpackten Anwendungen und Diensten über CheckNetIsolation.exe verbunden wird. Dies ist jedoch nur für Querladen- oder Debuggingszenarien möglich, in denen Sie lokalen Zugriff auf den Computer haben und über Administratorrechte verfügen.

• Alle verpackten Anwendungen, die an Loopbackverbindungen teilnehmen, müssen die privateNetworkClientServer-Funktion in ihren Paketmanifesten deklarieren.
• Wenn eine verpackte Anwendung eine Verbindung mit einer entpackten Anwendung oder einem Dienst herstellt, führen Sie CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> aus, um eine Loopbackausnahme für die verpackte Anwendung hinzuzufügen.
• Wenn eine entpackte Anwendung oder ein Dienst eine Verbindung mit einer verpackten Anwendung herstellt, führen Sie CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> aus, um die verpackte Anwendung zum Empfangen eingehender Loopbackverbindungen zu aktivieren.
  • CheckNetIsolation.exe muss kontinuierlich ausgeführt werden, während die verpackte Anwendung auf Verbindungen lauscht.
  • Das -is-Flag wurde in Windows 10, Version 1607 (10.0; Build 14393) eingeführt.

Hinweis

Der Paketfamilienname, der für das -n-Flag von CheckNetIsolation.exe erforderlich ist, finden Sie im Paketmanifest-Editor in Visual Studio während der Entwicklungszeit, über Partner Center für Anwendungen, die über den Microsoft Store veröffentlicht wurden, oder über den PowerShell-Befehl „Get-AppxPackage“ für Anwendungen, die bereits installiert sind.

CheckNetIsolation.exe ist auch hilfreich beim Debuggen von Netzwerkisolationsproblemen.

Pipes

Pipes ermöglichen einfache prozessübergreifende Kommunikation zwischen einem Pipe-Server und einem oder mehreren Pipe-Clients.

Anonyme Pipes und Named Pipes werden mit den folgenden Einschränkungen unterstützt:

• Standardmäßig werden benannte Pipes in verpackten Anwendungen nur zwischen Prozessen innerhalb desselben Pakets unterstützt, es sei denn, ein Prozess ist voll vertrauenswürdig.
• Benannte Pipes können über Pakete hinweg freigegeben werden, die den Richtlinien für die Freigabe benannter Objekte folgen.
• Benannte Pipes (in verpackten und entpackten Apps) müssen die Syntax \\.\pipe\LOCAL\ für den Pipenamen verwenden.

Registrierung

Von der Registrierungsverwendung für IPC wird im Allgemeinen abgeraten, jedoch wird sie für vorhandenen Code unterstützt. Verpackte Anwendungen können nur auf Registrierungsschlüssel zugreifen, auf die sie über die Berechtigung zum Zugriff verfügen.

Häufig nutzen verpackte Desktop-Apps (siehe Erstellen eines MSIX-Pakets aus Ihrem Code) die Registrierungsvirtualisierung, sodass globale Registrierungsschreibvorgänge in einem privaten Hive im MSIX-Paket enthalten sind. Dies ermöglicht die Kompatibilität von Quellcode und minimiert gleichzeitig die Auswirkungen auf die globale Registrierung und kann für IPC zwischen Prozessen im selben Paket verwendet werden. Wenn Sie die Registrierung verwenden müssen, wird dieses Modell bevorzugt, anstatt die globale Registrierung zu bearbeiten.

RPC

RPC kann verwendet werden, um eine verpackte Anwendung mit einem Win32-RPC-Endpunkt zu verbinden, vorausgesetzt, die verpackte Anwendung verfügt über die richtigen Funktionen zum Abgleichen der ACLs auf dem RPC-Endpunkt.

Benutzerdefinierte Funktionen ermöglichen OEMs und IHVs, beliebige Funktionen zu definieren, ihre RPC-Endpunkte mit ihnen zu ACL-en und diese Funktionen dann autorisierten Clientanwendungen zu gewähren. Eine vollständige Beispielanwendung finden Sie im CustomCapability-Beispiel.

RPC-Endpunkte können auch auf bestimmte verpackte Anwendungen ge-ACLt werden, um den Zugriff auf den Endpunkt auf diese Anwendungen zu beschränken, ohne dass der Verwaltungsaufwand für benutzerdefinierte Funktionen erforderlich ist. Sie können die DeriveAppContainerSidFromAppContainerName-API verwenden, um eine SID von einem Paketfamiliennamen abzuleiten, und dann den RPC-Endpunkt mit der SID ACL-en, wie im CustomCapability-Beispiel gezeigt.

Gemeinsam genutzter Speicherbereich

Die Dateizuordnung kann zum Freigeben einer Datei oder eines Arbeitsspeichers zwischen zwei oder mehr Prozessen mit den folgenden Einschränkungen verwendet werden:

• Standardmäßig werden Dateizuordnungen in verpackten Anwendungen nur zwischen Prozessen innerhalb desselben Pakets unterstützt, es sei denn, ein Prozess ist voll vertrauenswürdig.
• Dateizuordnungen können über Pakete hinweg freigegeben werden, die den Richtlinien für die Freigabe benannter Objekte folgen.

Der gemeinsam genutzte Speicherbereich wird empfohlen, um große Datenmengen effizient freizugeben und zu bearbeiten.