Comunicação entre processos (IPC)

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 Win32.

Serviços aplicacionais

Os serviços de aplicações permitem que os aplicativos exponham serviços que aceitam e retornem conjuntos de propriedades de primitivos (ValueSet) em segundo plano. Objetos ricos podem ser passados se forem serializados.

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

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

COM

COM é um sistema distribuído orientado a objetos para a criação de componentes de software binários 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 do processo, e podem comunicar-se através de um modelo cliente-servidor . Os servidores 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 registar servidores COM fora de processo para IPC através do manifesto de pacote . Isso é conhecido como Packaged COM.

Sistema de arquivos

AcessoAmploAoSistemaDeFicheiros

As aplicações empacotadas podem executar IPC usando o sistema de ficheiros amplo, declarando a capacidade restrita broadFileSystemAccess. Este recurso concede APIs Windows.Storage e APIs xxxFromApp Win32 acesso ao sistema de arquivos completo.

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

PublisherCacheFolder

O PublisherCacheFolder permite que aplicações empacotadas declarem pastas no seu manifesto que podem ser partilhadas 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 copiados ou sincronizados.
• O usuário pode limpar o conteúdo da pasta de armazenamento compartilhado.
• Não é possível usar a pasta de armazenamento compartilhado para compartilhar dados entre aplicativos de editores diferentes.
• Não é possível 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 é uma opção simples baseada em sistema de arquivos.

Gestor de Armazenamento de Acesso Partilhado

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 de runFullTrust, as aplicações empacotadas podem iniciar processos de confiança total dentro do mesmo pacote.

Para cenários em que as restrições de pacote são um fardo, ou faltam opções de IPC, uma aplicação pode usar um processo com total confiança como um proxy para interagir com o sistema e, em seguida, realizar IPC com esse mesmo processo de total confiança através de serviços de aplicação ou outro mecanismo de IPC bem suportado.

LaunchUriForResultsAsync

LaunchUriForResultsAsync é usado para troca de dados simples (ValueSet) com outras aplicações em pacotes 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 de SharedStorageAccessManager para o aplicativo por meio do ValueSet.

Loopback

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

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

• Todas as aplicações empacotadas que participam de conexões de loopback precisarão declarar o recurso de privateNetworkClientServer nos seus manifests de pacote .
• Duas aplicações empacotadas podem comunicar-se através de loopback declarando LoopbackAccessRules nos manifestos dos seus pacotes.
  • Cada aplicativo deve listar o outro em seu LoopbackAccessRules. O cliente declara uma regra "de saída" para o servidor e o servidor declara regras "de entrada" para os seus clientes suportados.

Aplicativos e serviços não empacotados não têm identidade de pacote, portanto, não podem ser declarados em LoopbackAccessRules. Você pode configurar um aplicativo empacotado para se conectar via loopback com aplicativos e serviços não empacotados via CheckNetIsolation.exe, no entanto, isso só é possível para cenários de sideload ou depuração em que você tem acesso local à máquina e tem privilégios de administrador.

• Todas as aplicações empacotadas que estabelecem conexões de loopback precisam declarar o recurso privateNetworkClientServer nos 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 estar em execução continuamente enquanto o aplicativo empacotado está a aguardar ligações.
  • O -is sinalizador foi introduzido no Windows 10, versão 1607 (10.0; Build 14393).

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

Tubos

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

São suportados os tubos anónimos e tubos nomeados com as seguintes restrições:

• Por padrão, os pipes nomeados em aplicações empacotadas são suportados 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 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.

Registo

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

Geralmente, aplicativos de área de trabalho empacotados (consulte Criando um pacote MSIX a partir de seu código) aproveitam de virtualização do registro para que as gravações globais do registro estejam contidas em um hive privado dentro do pacote MSIX. Isso permite a compatibilidade do código-fonte enquanto minimiza o impacto global do registro e pode ser usado para IPC entre processos no mesmo pacote. Se tiver de utilizar o registo, este modelo é preferível à manipulação do registo global.

RPC

RPC pode ser usado para conectar um aplicativo empacotado a um ponto de extremidade RPC Win32, desde que o aplicativo empacotado tenha os recursos corretos para corresponder às ACLs no ponto de extremidade RPC.

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

Os pontos de extremidade RPC também podem ser configurados com ACLs para aplicações específicas empacotadas, com o objetivo de limitar o acesso ao ponto de extremidade apenas a essas aplicações, sem a necessidade da sobrecarga de gestão de capacidades personalizadas. Você pode usar a API DeriveAppContainerSidFromAppContainerName para derivar um SID a partir de um nome de pacote de família, e depois configurar a ACL no ponto de extremidade RPC com o SID, conforme mostrado no exemplo CustomCapability.

Memória compartilhada

de mapeamento de arquivos 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 são suportados apenas entre processos dentro do mesmo pacote, a menos que um processo seja totalmente confiável.
• Os mapeamentos de arquivos 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.