Como um aplicativo Metro no Windows 8 pode se comunicar com um aplicativo de desktop back-end na mesma máquina?

Em uma situação em que você constrói o front-end da interface do usuário usando o novo estilo Metro de aplicativos para Windows 8 e gostaria que ele se comunicasse com um aplicativo .NET em execução na área de trabalho na mesma máquina local (por exemplo, um aplicativo de serviço do Windows).

Quais formas de comunicação entre processos estão disponíveis entre o aplicativo metro e o aplicativo de desktop?

Agradecemos a Pavel Minaev, da equipe do Visual Studio, que forneceu algumas informações iniciais aqui em um comentário, citando:

Segundo Martyn Lovell, não existe nenhum mecanismo deliberado para isso, e alguns que poderiam ser usados ​​para isso são intencionalmente restritos. Os pipes nomeados não estão lá, por exemplo, nem os arquivos mapeados na memória. Existem soquetes (incluindo soquetes de servidor), mas ao conectar-se ao host local, você pode conectar-se apenas ao mesmo aplicativo. Você pode usar arquivos normais em uma das "pastas conhecidas" compartilhadas (Documentos, Imagens, etc.), mas esse é um hack razoavelmente grosseiro que requer pesquisa e fica visível para o usuário. - Pavel Minaev comentando sobre esta questão

Por isso, falhando nas abordagens normais, eu estava pensando em usar serviços da Web ou ler / gravar em um banco de dados para obter alguma forma de comunicação, que parece um exagero quando os processos estão em execução na mesma máquina.

O que estou tentando aqui faz sentido? Percebo a necessidade de um aplicativo de metrô ser a interface do usuário de front-end para um serviço existente em execução na área de trabalho. Ou é melhor usar apenas o WPF para a interface do usuário front-end em execução na área de trabalho (por exemplo, um aplicativo não metropolitano).

Estou portando meu projeto existente para o Win8 agora. Consiste no serviço do Windows e no aplicativo de bandeja que estão conversando via NamedPipes WCF. Como você já deve saber, o Metro não suporta pipes nomeados. Acabei usando TcpBinding para conexão full duplex.

Esta publicação descreve quais funcionalidades são suportadas.

A amostra do meu servidor WCF que o cliente Metro pode consumir está aqui .

Lembre-se também de que você não pode usar o WCF síncrono no Metro. Você precisará usar o wrapper baseado em tarefas, que é apenas assíncrono.

E obrigado pela sua pergunta. Eu era um bom ponto de partida para mim :)

Havia várias perguntas como essa no final de uma // compilação / sessão em que participei. Aleš Holeček, o executivo que fez uma das sessões mais importantes, saiu da platéia para lidar com elas. Mesmo que você não seja um desenvolvedor de C ++, faça o download dessa sessão e assista às perguntas e respostas http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Os aplicativos Metro não podem contar com aplicativos ou serviços de desktop instalados na máquina. E os aplicativos de desktop não podem contar com os aplicativos Metro em execução, pois podem ser suspensos a qualquer momento. Você precisa começar a pensar de maneira diferente. Ouça Aleš neste.

Observe que, com o Windows 8.1 Update, a comunicação entre os aplicativos da Windows Store e os componentes da área de trabalho escritos em C # for .NET 4.5+ agora é oficialmente suportada para aplicativos de carregamento lateral em cenários corporativos:

Componentes de tempo de execução do Windows intermediados para aplicativos da Windows Store carregados lateralmente

Citar:

Reconhecendo que regras e funções críticas de negócios estão incorporadas nos ativos de software existentes e que as empresas têm uma ampla variedade de cenários para os quais o novo estilo de aplicativo será altamente produtivo, o Windows 8.1 Update inclui um novo recurso chamado Brokered Windows Runtime Components para componentes carregados lateralmente formulários. Usamos o termo IPC (comunicação entre processos) para descrever a capacidade de executar ativos de software de desktop existentes em um processo (componente de desktop) enquanto interagimos com esse código em um aplicativo da Windows Store. Esse é um modelo familiar para desenvolvedores corporativos, pois aplicativos de banco de dados e aplicativos que utilizam os Serviços NT no Windows compartilham uma arquitetura de múltiplos processos semelhante.

Embora a implementação dessa abordagem seja um pouco complicada inicialmente, ela permite uma profunda integração na Windows Store e nos componentes da área de trabalho. Lembre-se de que, por enquanto, não passará na certificação pública da Windows Store.

Há um artigo no InfoQ sobre como criar aplicativos Metro fracamente acoplados com manipuladores de protocolo. Isso é algo que é suportado pelo Windows há muito tempo e é possível prever que um aplicativo de desktop se registre como manipulador de protocolo e talvez o aplicativo metro possa se comunicar através desse mecanismo.

Não tenho idéia se isso é possível, mas pode ser interessante verificar.

Christophe Nasarre publicou um blog sobre uma maneira bastante invasiva de fazê-lo usando arquivos locais. O resultado é a comunicação entre o aplicativo de desktop / aplicativo da Windows Store (conhecido como DA / WSA no blog), sem ter que alternar entre a interface dos dois aplicativos. Ele também escreveu sobre outra técnica menos invasiva, envolvendo manipuladores de protocolo.

Observe que ter um WSA que se comunica com um DA é explicitamente proibido pelos requisitos de certificação de aplicativos da loja

Os aplicativos da Windows Store não devem se comunicar com aplicativos ou serviços da área de trabalho local por mecanismos locais, incluindo arquivos e chaves do Registro.

... mas restringe apenas "mecanismos locais". Então, acho que se pode criar um serviço da web para rotear as comunicações.

Se você acha que pode fazer uma operação manual adicional do cmd, tente:

X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;

O CheckNetIsolation.exe está incluído na instalação do winRT, portanto não há nada extra a ser instalado.

Eu tentei: funciona, mesmo após a atualização do pacote.

Conforme mostrado em: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Aqui está explicado como descobrir o ID do pacote do seu aplicativo: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- o appid-de-um-metro-estilo-app-

É possível se comunicar na mesma máquina do aplicativo Metro para o aplicativo de desktop usando o serviço local. Eu implementei há algum tempo atrás uma simples "prova de conceito", como ignorar a sandbox do WinRT usando o serviço local. Ele ainda precisa de algum tipo de "engenharia social" ou guia direto para instalar o serviço, mas, de qualquer maneira, é possível.
No entanto, não tenho certeza sobre as regras de certificação sobre a comunicação "serviço local" ao adicionar esse aplicativo à Windows Store.

Amostra aqui

Por design, o aplicativo Metro não pode acessar diretamente o PC subjacente, apenas usando a API do WinRT e os recursos disponíveis. Mas quando você cria um serviço de back-end para acessar o PC e todos os dados existentes, ele basicamente não está mais em execução na sandbox.

O único "problema" é que o usuário deve instalar manualmente esse serviço de back-end, mas isso não será um problema ao usar alguma "engenharia social": o usuário baixa o aplicativo Metro "PC browser", o usuário pode navegar por todas as fotos, músicas e vídeos , usando a API do WinRT, mas o aplicativo também mostra uma mensagem na parte inferior: "Faça o download do powerpack do navegador do seu PC e navegue gratuitamente em todo o seu PC"

O usuário é redirecionado para a página da Web, de onde o usuário pode baixar o instalador clássico da área de trabalho que contém o serviço de back-end "Navegador do PC" para acessar arquivos no PC inteiro do usuário. Depois que esse serviço de desktop é instalado, o aplicativo Metro pode detectá-lo e usá-lo para navegar em todo o PC. O usuário está feliz, mas a sandbox do WinRT está comprometida.

Obviamente, isso não funcionará nos tablets ARM do Windows 8. Usando essa solução alternativa, pode ser possível criar clientes de aplicativos Metro para aplicativos de desktop clássicos, como antivírus, clientes de torrent / P2P etc.

Talvez eu tenha perdido o objetivo, mas ao ativar o recurso de redes privadas, posso conectar-me a um servidor local (http) em execução usando o endereço IP local (não o host local). Isso permite o meu cenário em que um aplicativo winrt se comunica com um aplicativo de desktop wpf