Compartir a través de


Comunicación entre procesos (IPC)

En este tema se explican varias maneras de realizar la comunicación entre procesos (IPC) entre aplicaciones de Plataforma universal de Windows (UWP) y aplicaciones Win32.

Servicios de aplicaciones

App Services permite a las aplicaciones exponer servicios que aceptan y devuelven bolsas de propiedades de primitivos (ValueSet) en segundo plano. Los objetos enriquecidos se pueden pasar si se serializan.

Los servicios de aplicaciones se pueden ejecutar fuera del proceso como una tarea en segundo plano o en proceso dentro de la aplicación en primer plano.

Los servicios de aplicaciones se usan mejor para compartir pequeñas cantidades de datos en los que no se requiere latencia casi en tiempo real.

COM

COM es un sistema distribuido y orientado a objetos para crear componentes de software binarios que pueden interactuar y comunicarse. Como desarrollador, se usa COM para crear componentes de software reutilizables y capas de automatización para una aplicación. Los componentes COM pueden estar en proceso o fuera del proceso, y pueden comunicarse a través de un modelo de cliente y servidor. Los servidores COM fuera de proceso se han usado durante mucho tiempo como medio para la comunicación entre objetos.

Las aplicaciones empaquetadas con la funcionalidad runFullTrust pueden registrar servidores COM fuera de proceso para IPC mediante el manifiesto del paquete. Esto se conoce como COM empaquetado.

Sistema de archivos

BroadFileSystemAccess

Las aplicaciones empaquetadas pueden realizar IPC mediante el amplio sistema de archivos declarando la funcionalidad restringida broadFileSystemAccess. Esta funcionalidad concede acceso a las API de Windows.Storage y a las API de Win32 xxxFromApp al amplio sistema de archivos.

De forma predeterminada, IPC a través del sistema de archivos para aplicaciones empaquetadas está restringido a los demás mecanismos descritos en esta sección.

PublisherCacheFolder

PublisherCacheFolder permite a las aplicaciones empaquetadas declarar carpetas en su manifiesto que el mismo publicador puede compartir con otros paquetes.

La carpeta de almacenamiento compartido tiene los siguientes requisitos y restricciones:

  • Los datos de la carpeta de almacenamiento compartido no se realiza una copia de seguridad ni se desplazan.
  • El usuario puede borrar el contenido de la carpeta de almacenamiento compartido.
  • No puedes usar la carpeta de almacenamiento compartido para compartir datos entre aplicaciones de distintos publicadores.
  • No puedes usar la carpeta de almacenamiento compartido para compartir datos entre distintos usuarios.
  • La carpeta de almacenamiento compartido no tiene administración de versiones.

Si publicas varias aplicaciones y buscas un mecanismo sencillo para compartir datos entre ellas, PublisherCacheFolder es una opción sencilla basada en el sistema de archivos.

SharedAccessStorageManager

SharedAccessStorageManager se usa junto con App Services, activaciones de protocolo (por ejemplo, LaunchUriForResultsAsync), etc., para compartir StorageFiles a través de tokens.

FullTrustProcessLauncher

Con la funcionalidad runFullTrust, las aplicaciones empaquetadas pueden iniciar procesos de plena confianza dentro del mismo paquete.

En escenarios en los que las restricciones de paquetes son una carga o faltan opciones de IPC, una aplicación podría usar un proceso de plena confianza como proxy para interactuar con el sistema y, a continuación, IPC con el proceso de plena confianza a través de App Services o algún otro mecanismo IPC bien compatible.

LaunchUriForResultsAsync

LaunchUriForResultsAsync se usa para el intercambio de datos simple (ValueSet) con otras aplicaciones empaquetadas que implementan el contrato de activación ProtocolForResults. A diferencia de App Services, que normalmente se ejecuta en segundo plano, la aplicación de destino se inicia en primer plano.

Los archivos se pueden compartir pasando tokens SharedStorageAccessManager a la aplicación a través de ValueSet.

Bucle invertido

Bucle invertido es el proceso de comunicación con un servidor de red que escucha en localhost (la dirección de bucle invertido).

Para mantener la seguridad y el aislamiento de red, las conexiones de bucle invertido para IPC se bloquean de forma predeterminada para las aplicaciones empaquetadas. Puedes habilitar conexiones de bucle invertido entre aplicaciones empaquetadas de confianza mediante funcionalidades y propiedades de manifiesto.

  • Todas las aplicaciones empaquetadas que participan en conexiones de bucle invertido deberán declarar la funcionalidad privateNetworkClientServer en sus manifiestos de paquete.
  • Dos aplicaciones empaquetadas se pueden comunicar a través de bucle invertido declarando LoopbackAccessRules dentro de sus manifiestos de paquete.
    • Cada aplicación debe enumerar la otra en su LoopbackAccessRules. El cliente declara una regla de "salida" para el servidor y el servidor declara reglas de "entrada" para sus clientes admitidos.

Nota:

El nombre de familia de paquete necesario para identificar una aplicación en estas reglas se puede encontrar a través del editor de manifiestos de paquete en Visual Studio durante el tiempo de desarrollo, a través del Centro de partners para aplicaciones publicadas a través de Microsoft Store, o mediante el comando Get-AppxPackage de PowerShell para aplicaciones que ya están instaladas.

Las aplicaciones y servicios sin empaquetar no tienen identidad de paquete, por lo que no se pueden declarar en LoopbackAccessRules. Puedes configurar una aplicación empaquetada para conectarse a través de bucle invertido con aplicaciones y servicios sin empaquetar a través de CheckNetIsolation.exe, pero esto solo es posible para escenarios de transferencia local o depuración en los que tienes acceso local a la máquina y tienes privilegios de administrador.

  • Todas las aplicaciones empaquetadas que participan en conexiones de bucle invertido deben declarar la funcionalidad privateNetworkClientServer en sus manifiestos de paquete.
  • Si una aplicación empaquetada se conecta a una aplicación o servicio sin empaquetar, ejecuta CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> para agregar una exención de bucle invertido para la aplicación empaquetada.
  • Si una aplicación o servicio sin empaquetar se conecta a una aplicación empaquetada, ejecuta CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> para permitir que la aplicación empaquetada reciba conexiones de bucle invertido de entrada.
    • CheckNetIsolation.exe debe ejecutarse continuamente mientras la aplicación empaquetada escucha las conexiones.
    • La marca -is se introdujo en Windows 10, versión 1607 (10.0; compilación 14393).

Nota:

El nombre de familia de paquete necesario para la marca -n de checkNetIsolation.exe se puede encontrar a través del editor de manifiestos de paquete en Visual Studio durante el tiempo de desarrollo, a través del Centro de partners para aplicaciones publicadas a través de Microsoft Store, o a través del comando Get-AppxPackage de PowerShell para las aplicaciones que ya están instaladas.

CheckNetIsolation.exe también es útil para depurar problemas de aislamiento de red.

Pipes (Operaciones de canalización de .NET Framework)

Las canalizaciones permiten la comunicación sencilla entre procesos entre un servidor de canalización y uno o varios clientes de canalización.

Las canalizaciones anónimas y las canalizaciones con nombre se admiten con las restricciones siguientes:

  • De forma predeterminada, las canalizaciones con nombre de las aplicaciones empaquetadas solo se admiten entre procesos dentro del mismo paquete, a menos que un proceso sea de plena confianza.
  • Las canalizaciones con nombre se pueden compartir entre paquetes siguiendo las instrucciones para compartir objetos con nombre.
  • Las canalizaciones con nombre (en aplicaciones empaquetadas y sin empaquetar) deben usar la sintaxis \\.\pipe\LOCAL\ para el nombre de canalización.

Registro

El uso del Registro para IPC suele desaconsejarse, pero se admite para el código existente. Las aplicaciones empaquetadas solo pueden acceder a las claves del Registro a las que tienen permiso de acceso.

Normalmente, las aplicaciones de escritorio empaquetadas (consulta Creación de un paquete MSIX a partir del código) aprovechan la virtualización del registro, de modo que las escrituras globales del registro están contenidas en un subárbol privado dentro del paquete MSIX. Esto permite la compatibilidad con el código fuente al minimizar el impacto global del registro y se puede usar para IPC entre procesos del mismo paquete. Si debes usar el registro, se prefiere este modelo frente a manipular el registro global.

RPC

RPC se puede usar para conectar una aplicación empaquetada a un punto de conexión RPC de Win32, siempre que la aplicación empaquetada tenga las funcionalidades correctas para que coincidan con las ACL en el punto de conexión RPC.

Las funcionalidades personalizadas permiten a los OEM e IHV definir funcionalidades arbitrarias, ACL sus puntos de conexión RPC con ellas y, a continuación, conceder esas funcionalidades a las aplicaciones cliente autorizadas. Para obtener una aplicación de ejemplo completa, consulta la muestra CustomCapability.

Los puntos de conexión RPC también se pueden agrupar en aplicaciones empaquetadas específicas para limitar el acceso al punto de conexión a solo esas aplicaciones sin requerir la sobrecarga de administración de funcionalidades personalizadas. Puedes usar la API DeriveAppContainerSidFromAppContainerName para derivar un SID de un nombre de familia de paquete y, a continuación, ACL el punto de conexión RPC con el SID como se muestra en el ejemplo CustomCapability.

Memoria compartida

La asignación de archivos se puede usar para compartir un archivo o memoria entre dos o más procesos con las restricciones siguientes:

  • De forma predeterminada, las asignaciones de archivos en las aplicaciones empaquetadas solo se admiten entre procesos dentro del mismo paquete, a menos que un proceso sea de plena confianza.
  • Las asignaciones de archivos se pueden compartir entre paquetes siguiendo las instrucciones para compartir objetos con nombre.

Se recomienda la memoria compartida para compartir y manipular grandes cantidades de datos de forma eficaz.