Compartilhar via

IPC (Comunicação Entre Processos)

  • Artigo

Este tópico explica várias maneiras de executar a comunicação entre processos (IPC) entre aplicativos da Plataforma Universal do Windows (UWP) e aplicativos do Win32.

Serviços de app

Os Serviços de Aplicativos permitem aos aplicativos expor serviços que aceitam e devolvem recipientes de propriedades de primitivas (ValueSet) em segundo plano. Objetos avançados podem ser passados se forem serializados.

Os Serviços de Aplicativos podem ser executados fora do processo como uma tarefa em segundo plano ou em processo no aplicativo em primeiro plano.

Os Serviços de Aplicativos são mais usados para compartilhar pequenos volumes de dados nos quais a latência quase em tempo real não é necessária.

COM

O COM é um sistema distribuído e orientado a objeto usado para criar componentes de software binários que possam interagir e se comunicar. Como desenvolvedor, você usa o COM para criar componentes de software reutilizáveis e camadas de automação para um aplicativo. Os componentes do COM podem estar em processo ou fora de processo e se comunicar por meio de um modelo de cliente e servidor. Os servidores do COM fora de processo têm sido usados há muito tempo como um meio de comunicação entre objetos.

Os aplicativos empacotados com a capacidade runFullTrust podem registrar servidores do COM fora de processo para IPC por meio do manifesto do pacote. Isso é conhecido como COM empacotado.

Sistema de arquivos

BroadFileSystemAccess

Os aplicativos empacotados podem executar o IPC usando o sistema de arquivos amplo, declarando a capacidade restrita broadFileSystemAccess. Essa capacidade concede às APIs do Windows.Storage e às APIs do Win32 xxxFromApp acesso ao sistema de arquivos amplo.

Por padrão, o IPC por meio do sistema de arquivos para aplicativos empacotados é restrito aos outros mecanismos descritos nesta seção.

PublisherCacheFolder

O PublisherCacheFolder permite que aplicativos empacotados declarem pastas no seu manifesto que podem ser compartilhadas com outros pacotes pelo mesmo fornecedor.

A pasta de armazenamento compartilhada tem os requisitos e as restrições a seguir.

  • Os dados na pasta de armazenamento compartilhada não são passíveis de backup ou roaming.
  • O usuário pode limpar o conteúdo da pasta de armazenamento compartilhada.
  • A pasta de armazenamento compartilhada não pode ser usada para compartilhar dados entre aplicativos de fornecedores diferentes.
  • A pasta de armazenamento compartilhada não pode ser usada para compartilhar dados entre usuários diferentes.
  • A pasta de armazenamento compartilhada não tem gerenciamento de versão.

Se você publica vários aplicativos e está procurando um mecanismo simples para compartilhar dados entre eles, o PublisherCacheFolder é uma opção simples baseada no sistema de arquivos.

SharedAccessStorageManager

O SharedAccessStorageManager é usado em conjunto com os Serviços de Aplicativos, as ativações de protocolo (por exemplo, LaunchUriForResultsAsync) etc., para compartilhar StorageFiles por meio de tokens.

FullTrustProcessLauncher

Com a capacidade runFullTrust, os aplicativos empacotados podem iniciar processos de confiança total no mesmo pacote.

Nos cenários em que as restrições de pacotes constituem um obstáculo ou faltam opções de IPC, um aplicativo pode usar um processo de confiança total como um proxy para fazer interface com o sistema e, em seguida, o IPC com o próprio processo de confiança total, por meio dos Serviços de Aplicativos ou algum outro mecanismo de IPC com boa compatibilidade.

LaunchUriForResultsAsync

O LaunchUriForResultsAsync é usado para a troca de dados simples (ValueSet) com outros aplicativos empacotados que implementam o contrato de ativação ProtocolForResults. Ao contrário dos Serviços de Aplicativos, que normalmente são executados em segundo plano, o aplicativo de destino é iniciado em primeiro plano.

Os arquivos podem ser compartilhados passando os tokens SharedStorageAccessManager para o aplicativo por meio do ValueSet.

Loopback

Loopback é o processo de comunicação com um servidor de rede ouvinte no localhost (o endereço de loopback).

Para manter a segurança e o isolamento de rede, as conexões de loopback para o IPC são bloqueadas por padrão para aplicativos empacotados. Você pode habilitar as conexões de loopback entre aplicativos empacotados confiáveis usando capacidades e propriedades de manifesto.

  • Todos os aplicativos empacotados que participam de conexões de loopback precisarão declarar a capacidade privateNetworkClientServer nos manifestos do pacote.
  • Dois aplicativos empacotados podem se comunicar por meio de loopback declarando LoopbackAccessRules nos manifestos do pacote.
    • Cada aplicativo deve listar o outro no LoopbackAccessRules. O cliente declara uma regra "out" para o servidor e o servidor declara regras "in" para seus clientes com suporte.

Observação

O nome da família de pacotes necessário para identificar um aplicativo nessas regras pode ser encontrado por meio do editor de manifesto do pacote no Visual Studio durante o tempo de desenvolvimento, por meio da Central de Parceiros para aplicativos publicados na Microsoft Store ou por meio do comando Get-AppxPackage do PowerShell para aplicativos que já estão instalados.

Aplicativos e serviços não empacotados não têm identificador de pacote; portanto, não podem ser declarados em LoopbackAccessRules. Você pode configurar um aplicativo empacotado para se conectar por meio de loopback com aplicativos e serviços não empacotados por meio de CheckNetIsolation.exe. No entanto, isso só é possível em cenários de sideload ou depuração nos quais você tem acesso local ao computador e privilégios de administrador.

  • Todos os aplicativos empacotados que participam de conexões de loopback precisam declarar a capacidade privateNetworkClientServer nos manifestos do pacote.
  • Se um aplicativo empacotado estiver se conectando a um aplicativo ou serviço não empacotado, execute CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> para adicionar uma isenção de loopback ao aplicativo empacotado.
  • Se um aplicativo ou serviço não empacotado estiver se conectando a um aplicativo empacotado, execute CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> para permitir que o aplicativo empacotado receba conexões de loopback de entrada.
    • O CheckNetIsolation.exe deve estar em execução contínua enquanto o aplicativo empacotado escuta conexões.
    • O sinalizador -is foi introduzido no Windows 10, versão 1607 (10.0; Build 14393).

Observação

O nome da família de pacotes necessário para o -n sinalizador de CheckNetIsolation.exe pode ser encontrado por meio do editor de manifesto do pacote no Visual Studio durante o tempo de desenvolvimento, por meio do Partner Center para aplicativos publicados por meio da Microsoft Store ou por meio do comando Get-AppxPackage do PowerShell para aplicativos que já estão instalados.

O CheckNetIsolation.exe também é útil para depurar problemas de isolamento de rede.

Pipes

Os pipes permitem a comunicação simples entre um servidor de pipes e um ou mais clientes de pipes.

Existe suporte para os pipes anônimos e os pipes nomeados, com as restrições a seguir.

  • Por padrão, só há suporte para pipes nomeados em aplicativos empacotados entre processos no mesmo pacote, a menos que um processo seja de confiança total.
  • Os pipes nomeados podem ser compartilhados entre pacotes seguindo as diretrizes de compartilhamento de objetos nomeados.
  • Os pipes nomeados (em aplicativos empacotados e não empacotados) devem usar a sintaxe \\.\pipe\LOCAL\ para o nome do pipe.

Registro

O uso do Registro para IPC geralmente é desencorajado, mas há suporte para código existente. Os aplicativos empacotados podem acessar somente as chaves do Registro que eles têm permissão para acessar.

Normalmente, os aplicativos para desktop empacotados (consulte Building an MSIX package from your code) aproveitam a virtualização do Registro de forma que as gravações globais do Registro estejam contidas em um hive privado no pacote do MSIX. Isso permite a compatibilidade do código-fonte enquanto minimiza o impacto do Registro global, podendo ser usado para o IPC entre processos no mesmo pacote. Se você precisar usar o Registro, esse modelo será preferível em vez de manipular o Registro global.

RPC

A RPC pode ser usada para conectar um aplicativo empacotado a um ponto de extremidade da RPC do Win32, desde que o aplicativo empacotado tenha as capacidades corretas para corresponder às ACLs no ponto de extremidade da RPC.

As capacidades personalizadas permitem que OEMs e IHVs definam capacidades arbitrárias, façam ACL de seus pontos de extremidade da RPC com elas e concedam essas capacidades a aplicativos clientes autorizados. Para obter um aplicativo de exemplo completo, consulte o exemplo CustomCapability.

Os pontos de extremidade da RPC também podem ser transformados em ACL para aplicativos empacotados específicos a fim de limitar o acesso ao ponto de extremidade apenas a esses aplicativos, dispensando a sobrecarga do gerenciamento de capacidades personalizadas. Você pode usar a API DeriveAppContainerSidFromAppContainerName para derivar uma SID de um nome da família de pacotes e, em seguida, fazer ACL do ponto de extremidade da RPC com a SID, conforme mostrado no exemplo CustomCapability.

Memória compartilhada

O mapeamento de arquivo pode ser usado para compartilhar um arquivo ou uma memória entre dois ou mais processos com as restrições a seguir.

  • Por padrão, só há suporte para mapeamentos de arquivo em aplicativos empacotados entre processos no mesmo pacote, a menos que um processo seja de confiança total.
  • Os mapeamentos de arquivo podem ser compartilhados entre pacotes seguindo as diretrizes de compartilhamento de objetos nomeados.

A memória compartilhada é recomendada para compartilhar e manipular com eficiência grandes quantidades de dados.