Interprozesskommunikation (IPC)

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

App-Dienste

App-Dienste ermöglichen es Anwendungen, Dienste bereitzustellen, die Eigenschaftscontainer von Grundtypen akzeptieren und zurückgeben (ValueSet-) im Hintergrund. Rich-Objekte können übergeben werden, wenn sie serialisiertensind.

App-Dienste können entweder außerhalb des Prozesses als Hintergrundaufgabe oder im Prozess innerhalb der Vordergrundanwendung ausführen.

App-Dienste eignen sich am besten für die Freigabe kleiner Datenmengen, bei denen nahezu in Echtzeit liegende Latenz nicht erforderlich ist.

COM

COM ist ein verteiltes, objektorientiertes System zum Erstellen binärer Softwarekomponenten, die 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 im Prozess oder außerhalb des Prozesses sein und sie können über ein Client- und Server--Modell kommunizieren. Out-of-Process-COM-Server werden seit langem als Mittel für interobjektübergreifende Kommunikationverwendet.

Verpackte Anwendungen mit der runFullTrust--Funktion können COM-Server außerhalb des Prozesses für die IPC über das -Paketmanifestregistrieren. Dies ist als verpacktes COM-bekannt.

Dateisystem

BroadFileSystemAccess

Verpackte Anwendungen können IPC mithilfe des allgemeinen Dateisystems ausführen, indem sie die broadFileSystemAccess eingeschränkte 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 gepackte Anwendungen auf die anderen Mechanismen beschränkt, die in diesem Abschnitt beschrieben werden.

PublisherCacheFolder

Mit dem PublisherCacheFolder- können verpackte Anwendungen Ordner in ihrem Manifest deklarieren, 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 leeren.
• Sie können den gemeinsam genutzten Speicherordner nicht zum Teilen von Daten zwischen Apps aus verschiedenen Herausgebern verwenden.
• Sie können den freigegebenen Speicherordner nicht verwenden, um Daten zwischen verschiedenen Benutzern zu teilen.
• Der geteilte Speicherordner hat keine 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.

Manager für gemeinsam genutzten Speicherzugriff

SharedAccessStorageManager wird in Verbindung mit App-Diensten und Protokollaktivierungen (z. B. LaunchUriForResultsAsync) verwendet, um StorageFiles über Token gemeinsam zu nutzen.

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-Dienste oder einen anderen gut unterstützten IPC-Mechanismus verwenden.

LaunchUriForResultsAsync

LaunchUriForResultsAsync- wird für den einfachen Austausch von (ValueSet-) Daten mit anderen verpackten Anwendungen verwendet, die den ProtocolForResults-Aktivierungsvertrag implementieren. Im Gegensatz zu App-Diensten, die in der Regel im Hintergrund ausgeführt werden, wird die Zielanwendung im Vordergrund gestartet.

Dateien können freigegeben werden, indem SharedStorageAccessManager Tokens über das ValueSet zur Anwendung übergeben werden.

Loopback

Loopback ist der Prozess der Kommunikation mit einem Netzwerkserver, der auf localhost lauscht (die Loopback-Adresse).

Um die Sicherheit und Netzwerkisolation aufrechtzuerhalten, werden Loopback-Verbindungen für die zwischenprozessuale Kommunikation (IPC) standardmäßig für gepackte Anwendungen blockiert. Sie können Loopbackverbindungen zwischen vertrauenswürdigen gepackten Anwendungen mithilfe der -Fähigkeiten und der -Manifest-Eigenschaftenaktivieren.

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

Hinweis

Den Paketfamiliennamen, der zum Identifizieren einer Anwendung in diesen Regeln erforderlich ist, finden Sie während der Entwicklungszeit über den Paketmanifest-Editor in Visual Studio, ü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.

Nicht gepackte Anwendungen und Dienste verfügen nicht über eine Paketidentität, sodass sie nicht in LoopbackAccessRules deklariert werden können. Sie können eine gepackte Anwendung so konfigurieren, dass sie über Loopback eine Verbindung mit nicht gepackten Anwendungen und Diensten überCheckNetIsolation.exeherstellt, dies ist jedoch nur für Querlade- oder Debugszenarien möglich, in denen Sie lokalen Zugriff auf den Computer haben und über Administratorrechte verfügen.

• Alle paketierten Anwendungen, die an Loopback-Verbindungen teilnehmen, müssen die Funktion privateNetworkClientServer in ihren Paketmanifesten deklarieren.
• Wenn eine gepackte Anwendung eine Verbindung mit einer nicht gepackten Anwendung oder einem nicht gepackten Dienst herstellt, führen Sie diese aus CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> , um eine Loopback-Ausnahme für die gepackte Anwendung hinzuzufügen.
• Wenn eine entpackte Anwendung oder ein Dienst sich mit einer gepackten Anwendung verbindet, führen Sie CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> aus, um der gepackten Anwendung den Empfang eingehender Loopback-Verbindungen zu ermöglichen.
  • CheckNetIsolation.exe muss kontinuierlich ausgeführt werden, während die Paket-Anwendung auf Verbindungen wartet.
  • 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, kann im Paketmanifest-Editor in Visual Studio während der Entwicklungszeit oder über Partner Center für im Microsoft Store veröffentlichte Anwendungen, oder über den Get-AppxPackage PowerShell-Befehl für bereits installierte Anwendungen gefunden werden.

CheckNetIsolation.exe ist auch für Debuggen von Netzwerkisolationsproblemennützlich.

Rohre

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

Anonyme Rohre und benannten Rohre 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 gemeinsam genutzt werden, indem die Richtlinien zur Freigabe benannter Objekte befolgt werden.
• Named Pipes (in gepackten und nicht gepackten Apps) müssen die Syntax \\.\pipe\LOCAL\ für den Pipenamen verwenden.

Registratur

Registrierung für IPC wird generell nicht empfohlen, ist jedoch für bestehenden Code unterstützt. Gepackte Anwendungen können nur auf Registrierungsschlüssel zugreifen, für die sie über die Berechtigung verfügen.

Verpackte Desktop-Apps (siehe Erstellen eines MSIX-Pakets aus Ihrem Code) nutzen häufig Registrierungsvirtualisierung, sodass globale Registrierungseinträge in einem privaten Hive innerhalb des MSIX-Pakets enthalten sind. Dies ermöglicht die Kompatibilität des Quellcodes bei gleichzeitiger Minimierung der 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, sofern die verpackte Anwendung über die richtigen Funktionen verfügt, um die ACLs auf dem RPC-Endpunkt abzugleichen.

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

RPC-Endpunkte können auch auf spezifische bereitgestellte Anwendungen ACL-basiert angewendet werden, um den Zugriff auf den Endpunkt auf nur diese Anwendungen zu beschränken, ohne den Verwaltungsaufwand für benutzerdefinierte Funktionen erforderlich zu machen. Sie können die DeriveAppContainerSidFromAppContainerName-API verwenden, um eine SID von einem Paketfamiliennamen abzuleiten und anschließend den RPC-Endpunkt mit der SID zu ACLen, wie im Beispiel CustomCapability gezeigt.

Gemeinsamer Speicher

Dateizuordnung kann verwendet werden, um eine Datei oder einen Speicher zwischen zwei oder mehr Prozessen mit den folgenden Einschränkungen zu teilen:

• 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 Objektefolgen.

Gemeinsamer Speicher wird empfohlen, um große Datenmengen effizient zu teilen und zu bearbeiten.