Compartilhar via

Comunicação entre processos (IPC)

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

Serviços de aplicativo

Os serviços de aplicativo permitem que os aplicativos exponham serviços que aceitam e retornam conjuntos de propriedades de tipos primitivos (ValueSet) em segundo plano. Objetos avançados podem ser passados se forem serializados.

Os serviços de aplicativo podem executar fora do processo como uma tarefa em segundo plano ou no processo dentro do aplicativo em primeiro plano.

Os serviços de aplicativo são melhor usados para compartilhar pequenas quantidades de dados em que a latência quase em tempo real não é necessária.

COM

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

Aplicativos empacotados com o recurso runFullTrust podem registrar servidores COM fora de processo para IPC por meio do manifesto do pacote . Isso é conhecido como COM empacotado.

Sistema de arquivos

BroadFileSystemAccess

Aplicativos empacotados podem executar IPC usando o sistema de arquivos amplo declarando a capacidade restrita broadFileSystemAccess. Esse recurso concede a APIs de do Windows.Storage e xxxFromApp acesso de APIs Win32 ao amplo sistema de arquivos.

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

PastaCacheEditora

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

A pasta de armazenamento compartilhado tem os seguintes requisitos e restrições:

  • Os dados na pasta de armazenamento compartilhado não são incluídos no backup nem sincronizados.
  • O usuário pode limpar o conteúdo da pasta de armazenamento compartilhado.
  • Você não pode usar a pasta de armazenamento compartilhado para compartilhar dados entre aplicativos de diferentes editores.
  • Você não pode usar a pasta de armazenamento compartilhado para compartilhar dados entre usuários diferentes.
  • A pasta de armazenamento compartilhado não tem gerenciamento de versão.

Se você publicar vários aplicativos e estiver procurando um mecanismo simples para compartilhar dados entre eles, o PublisherCacheFolder será uma opção simples baseada em sistema de arquivos.

Gerenciador de Armazenamento de Acesso Compartilhado

SharedAccessStorageManager é usado em conjunto com serviços de aplicativo, 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 dentro do mesmo pacote.

Para cenários em que as restrições de pacote são um obstáculo ou faltam opções de Comunicação Inter-Processos (IPC), um aplicativo pode usar um processo de confiança plena como um proxy para interface com o sistema e depois realizar a IPC com o próprio processo de confiança plena por meio de serviços de aplicativo ou algum outro mecanismo de IPC amplamente suportado.

LaunchUriForResultsAsync

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

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

Loopback

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

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

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

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 do do Partner Center para aplicativos publicados por meio da Microsoft Store ou por meio do comando Get-AppxPackage PowerShell para aplicativos que já estão instalados.

Aplicativos e serviços não empacotados não têm identidade de pacote, portanto, eles não podem ser declarados em LoopbackAccessRules. Você pode configurar um aplicativo empacotado para se conectar a aplicativos e serviços não empacotados via loopback usando 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 funcionalidade privateNetworkClientServer em seus manifestos de 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 para o 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.
    • CheckNetIsolation.exe deve ser executado continuamente enquanto o aplicativo empacotado está ouvindo 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 sinalizador -n de CheckNetIsolation.exe pode ser encontrado por meio do editor de manifesto do pacote no Visual Studio durante o desenvolvimento, por meio do 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.

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

Tubos

Pipes habilitam a comunicação simples entre um servidor e um ou mais clientes.

Tubulações anônimas e tubulações nomeadas têm suporte com as seguintes restrições:

  • Por padrão, pipes nomeados em aplicativos empacotados têm suporte apenas entre processos dentro do mesmo pacote, a menos que um processo seja de confiança total.
  • Os pipes nomeados podem ser compartilhados entre pacotes seguindo as diretrizes para o 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 ele é suportado para código existente. Os aplicativos empacotados podem acessar somente as chaves do Registro que têm permissão para acessar.

Normalmente, os aplicativos de área de trabalho empacotados (consulte a criação de um pacote MSIX a partir do seu código) aproveitam a virtualização do registro , de modo que as gravações globais no registro estejam contidas em um hive privado dentro do pacote MSIX. Isso permite a compatibilidade do código-fonte minimizando o impacto global do registro e pode ser usado para IPC entre processos no mesmo pacote. Se você precisar usar o Registro, esse modelo será preferencial versus manipular o registro global.

RPC

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

Os recursos personalizados permitem que OEMs e IHVs definam definir recursos arbitrários, ACL seus pontos de extremidade RPC com elese, em seguida, conceder esses recursos a aplicativos cliente autorizados. Para obter um aplicativo de exemplo completo, consulte o exemplo de CustomCapability.

Os pontos de extremidade RPC também podem ter listas de controle de acesso aplicadas para aplicativos empacotados específicos, limitando o acesso ao ponto de extremidade exclusivamente a esses aplicativos, sem exigir a sobrecarga de gerenciamento de capacidades personalizadas. Você pode usar a API DeriveAppContainerSidFromAppContainerName para derivar um SID a partir de um nome de família de pacotes e, em seguida, configurar a ACL do ponto de extremidade RPC com o SID, conforme mostrado no exemplo CustomCapability.

Memória Compartilhada

Mapeamento de arquivo pode ser usado para compartilhar um arquivo ou memória entre dois ou mais processos com as seguintes restrições:

  • Por padrão, os mapeamentos de arquivos em aplicativos empacotados têm suporte apenas entre processos dentro do mesmo pacote, a menos que um processo seja de confiança total.
  • Os mapeamentos de arquivo podem ser compartilhados entre pacotes seguindo as diretrizes para compartilhamento de objetos nomeados.

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