Communication interprocesseur (IPC)

Cette rubrique explique différentes façons d’effectuer une communication interprocesseur (IPC) entre les applications de plateforme Windows universelle (UWP) et les applications Win32.

Services d’application

Les services d'application permettent aux applications d'exposer des services qui, en arrière-plan, acceptent et retournent des ensembles de valeurs de primitives (ValueSet). Les objets complexes peuvent être transmis s’ils sont sérialisés.

Les services d’application peuvent exécuter hors processus en tant que tâche en arrière-plan, ou dans les de processus au sein de l’application de premier plan.

Les services d’application sont mieux utilisés pour partager de petites quantités de données où la latence en quasi temps réel n’est pas nécessaire.

COM

COM est un système distribué orienté objet permettant de créer des composants logiciels binaires qui peuvent interagir et communiquer. En tant que développeur, vous utilisez COM pour créer des composants logiciels réutilisables et des couches d’automatisation pour une application. Les composants COM peuvent être en cours ou hors processus, et ils peuvent communiquer via un modèle client et serveur. Les serveurs COM hors processus ont depuis longtemps été utilisés comme moyen de communication inter-objets.

Les applications empaquetées avec la fonctionnalité runFullTrust peuvent inscrire des serveurs COM hors processus pour la communication interprocessus (IPC) via le manifeste de paquet . Il s’agit duCOM empaqueté .

Système de fichiers

BroadFileSystemAccess

Les applications empaquetées peuvent effectuer l’IPC à l’aide du système de fichiers étendu en déclarant la fonctionnalité broadFileSystemAccess restreinte. Cette fonctionnalité accorde API windows.Storage et xxxFromApp l’accès aux API Win32 au système de fichiers étendu.

Par défaut, IPC via le système de fichiers pour les applications empaquetées est limité aux autres mécanismes décrits dans cette section.

PublisherCacheFolder

Le PublisherCacheFolder permet aux applications empaquetées de déclarer des dossiers dans leur manifeste qui peuvent être partagés avec d’autres packages par le même éditeur.

Le dossier de stockage partagé présente les exigences et restrictions suivantes :

• Les données dans le dossier de stockage partagé ne sont ni sauvegardées ni synchronisées.
• L’utilisateur peut effacer le contenu du dossier de stockage partagé.
• Vous ne pouvez pas utiliser le dossier de stockage partagé pour partager des données entre des applications provenant de différents éditeurs.
• Vous ne pouvez pas utiliser le dossier de stockage partagé pour partager des données entre différents utilisateurs.
• Le dossier de stockage partagé n’a pas de gestion des versions.

Si vous publiez plusieurs applications et que vous recherchez un mécanisme simple pour partager des données entre elles, publisherCacheFolder est une option simple basée sur le système de fichiers.

SharedAccessStorageManager

SharedAccessStorageManager est utilisé conjointement avec les services d’application, les activations de protocole (par exemple, LaunchUriForResultsAsync), etc., pour partager StorageFiles via des jetons.

FullTrustProcessLauncher

Avec la fonctionnalité runFullTrust, les applications empaquetées peuvent lancer des processus de confiance totale au sein du même package.

Pour les scénarios où les restrictions de package sont un fardeau ou que les options IPC manquent, une application peut utiliser un processus de confiance totale en tant que proxy pour interagir avec le système, puis IPC avec le processus de confiance totale lui-même via App Services ou un autre mécanisme IPC bien pris en charge.

LaunchUriForResultsAsync

LaunchUriForResultsAsync est utilisé pour l’échange de données simple (ValueSet) avec d’autres applications empaquetées qui implémentent le contrat d’activation ProtocolForResults. Contrairement aux services d’application, qui s’exécutent généralement en arrière-plan, l’application cible est lancée au premier plan.

Les fichiers peuvent être partagés en passant SharedStorageAccessManager jetons à l’application via ValueSet.

Bouclage

Le bouclage est le processus de communication avec un serveur réseau qui écoute sur localhost (l'adresse de bouclage).

Pour maintenir la sécurité et l’isolation réseau, les connexions de boucle locale pour IPC sont bloquées par défaut pour les applications empaquetées. Vous pouvez activer les connexions de bouclage entre les applications empaquetées approuvées à l’aide de fonctionnalités et propriétés de manifeste.

• Toutes les applications empaquetées participant à des connexions de bouclage doivent déclarer la fonctionnalité privateNetworkClientServer dans le manifeste de package de .
• Deux applications empaquetées peuvent communiquer en utilisant un loopback en déclarant LoopbackAccessRules dans le manifeste de paquet.
  • Chaque application doit répertorier l'autre dans son LoopbackAccessRules. Le client déclare une règle « out » pour le serveur, et le serveur déclare des règles « in » pour ses clients pris en charge.

Les applications et services non empaquetés n’ont pas d’identité de package. Ils ne peuvent donc pas être déclarés dans LoopbackAccessRules. Vous pouvez configurer une application empaquetée pour vous connecter via un bouclage avec des applications et des services non empaquetés via CheckNetIsolation.exe, mais cela n’est possible que pour les scénarios de chargement indépendant ou de débogage où vous avez un accès local à l’ordinateur et que vous disposez de privilèges d’administrateur.

• Toutes les applications empaquetées participant à des connexions de bouclage doivent déclarer la fonctionnalité privateNetworkClientServer dans leur manifeste de paquet .
• Si une application empaquetée se connecte à une application ou un service non empaqueté, exécutez CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> pour ajouter une exemption de bouclage pour l’application empaquetée.
• Si une application ou un service non empaqueté se connecte à une application empaquetée, exécutez CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> pour permettre à l’application empaquetée de recevoir des connexions de bouclage entrantes.
  • CheckNetIsolation.exe devez être en cours d’exécution en continu pendant que l’application empaquetée écoute les connexions.
  • L’indicateur -is a été introduit dans Windows 10, version 1607 (10.0 ; Build 14393).

CheckNetIsolation.exe est également utile pour débogage des problèmes d’isolation réseau.

Tuyaux

Pipes permettent une communication simple entre un serveur de pipes et un ou plusieurs clients de pipes.

canaux anonymes et canaux nommés sont pris en charge sous réserve des contraintes suivantes :

• Par défaut, les canaux nommés dans les applications empaquetées sont pris en charge uniquement entre les processus du même package, sauf si un processus est de confiance totale.
• Les canaux nommés peuvent être partagés entre les packages en suivant les directives pour le partage d'objets nommés .
• Les canaux nommés (dans les applications empaquetées et non empaquetées) doivent utiliser la syntaxe \\.\pipe\LOCAL\ du nom du canal.

Registre

l'utilisation du Registre pour la communication inter-processus (IPC) est généralement déconseillée, mais elle est prise en charge pour le code existant. Les applications empaquetées peuvent accéder uniquement aux clés de Registre auxquelles elles sont autorisées à accéder.

Couramment, les applications de bureau empaquetées (voir Génération d’un package MSIX à partir de votre code) tirent parti de virtualisation du Registre de sorte que les écritures de registre globales soient contenues dans une ruche privée dans le package MSIX. Cela permet la compatibilité du code source tout en réduisant l’impact global du registre et peut être utilisée pour l’IPC entre les processus du même package. Si vous devez utiliser le Registre, ce modèle est préféré par rapport à la manipulation du registre global.

Réf.

RPC peut être utilisé pour connecter une application empaquetée à un point de terminaison RPC Win32, à condition que l’application empaquetée dispose des fonctionnalités appropriées pour correspondre aux listes de contrôle d’accès sur le point de terminaison RPC.

Les fonctionnalités personnalisées permettent aux oem et aux IMV de de définir des fonctionnalités arbitraires, ACL leurs points de terminaison RPC avec eux, puis accorder ces fonctionnalités aux applications clientes autorisées. Pour obtenir un exemple d’application complet, consultez l’exemple CustomCapability.

Les points de terminaison RPC peuvent également être soumis à des ACL pour des applications packagées spécifiques, afin de limiter l’accès au point de terminaison à ces applications, sans nécessiter la complexité de gestion des fonctionnalités personnalisées. Vous pouvez utiliser l’API DeriveAppContainerSidFromAppContainerName pour dériver un SID à partir d’un nom de famille de package, puis ACL le point de terminaison RPC avec le SID, comme indiqué dans l’exemple CustomCapability.

Mémoire partagée

de mappage de fichiers peut être utilisé pour partager un fichier ou une mémoire entre deux processus ou plus avec les contraintes suivantes :

• Par défaut, les mappages de fichiers dans les applications empaquetées sont pris en charge uniquement entre les processus au sein du même package, sauf si un processus est de confiance totale.
• Les mappages de fichiers peuvent être partagés entre les packages en suivant les instructions pour partage d’objets nommés.

La mémoire partagée est recommandée pour partager et manipuler efficacement de grandes quantités de données.