¿Cómo se puede comunicar una aplicación Metro en Windows 8 con una aplicación de escritorio backend en la misma máquina?

120

En una situación en la que tiene la interfaz de la interfaz de usuario construida con el nuevo estilo Metro de aplicaciones para Windows 8 y le gustaría que se comunique con una aplicación .NET que se ejecuta en el escritorio en la misma máquina local (por ejemplo, una aplicación de servicio de Windows).

¿Qué formas de comunicación entre procesos están disponibles entre la aplicación metro y la aplicación de escritorio?

Gracias a Pavel Minaev del equipo de Visual Studio, que ha proporcionado información inicial aquí en un comentario, citado:

Según Martyn Lovell, no existe ningún mecanismo deliberado para eso, y algunos que podrían usarse para ello están intencionalmente restringidos. Las canalizaciones con nombre no existen, por ejemplo, ni los archivos mapeados en memoria. Hay sockets (incluidos los sockets del servidor), pero cuando se conecta a localhost, solo puede conectarse a la misma aplicación. Podrías usar archivos normales en una de las "carpetas conocidas" compartidas (Documentos, Imágenes, etc.), pero ese es un truco bastante tosco que requiere sondeo y es visible para el usuario. - Pavel Minaev comentando sobre este tema.

Entonces, al fallar los enfoques normales, estaba pensando en usar servicios web o leer / escribir en una base de datos para que ocurriera alguna forma de comunicación, lo cual parece excesivo cuando los procesos se ejecutan en la misma máquina.

¿Tiene sentido lo que intento aquí? Puedo ver la necesidad de que una aplicación de metro sea la interfaz de usuario de un servicio existente que se ejecuta en el escritorio. ¿O es mejor simplemente usar WPF para la interfaz de usuario de la interfaz que se ejecuta en el escritorio (es decir, una aplicación que no sea metro)?

c# wpf winapi windows-8 windows-runtime dodgy_coder
fuente
2
¿Qué pasa con un servicio WCF local?
Gleno
2
@Gleno que estaría cubierto de "pensar en usar servicios web" en la pregunta. Dicho esto, me pregunto si funcionará, si la implementación de la biblioteca de cliente WCF que se proporciona en .NET Core está construida sobre los sockets de WinRT, entonces presumiblemente se aplicaría la misma restricción "sin localhost". Esto debe comprobarse.
Pavel Minaev
1
Parece que NetNamedPipeBinding y NetTcpBinding de WCF (sobre localhost) no estarían disponibles de todos modos debido a las restricciones en el metro. ¿Eso dejaría los servicios web o los enlaces MSMQ? Para ser honesto, no estoy seguro de si WCF está disponible en metro.
dodgy_coder
6
Permítame darle la vuelta a su pregunta y preguntarle: ¿Qué sucede si el servicio de escritorio con el que se está comunicando no está presente? Recuerde que su aplicación solo se puede instalar desde la tienda y, por lo tanto, no puede depender de la presencia del servicio de escritorio.
Reincorporar a Monica Larry Osterman
3
Parece que las empresas pueden descargar aplicaciones personalizadas y omitir la Tienda Windows. Si es así, tendría sentido asumir que algunas aplicaciones se están ejecutando en el entorno empresarial. Dicho esto, creo que el póster original debería usar una interfaz de escritorio WPF para sus propósitos.
Ankur Goel

Respuestas:

54

Estoy portando mi proyecto existente a Win8 en este momento. Consiste en el servicio de Windows y la aplicación de bandeja que se comunican entre sí a través de NamedPipes WCF. Como ya sabrá, Metro no admite tuberías con nombre. Terminé usando TcpBinding para una conexión full duplex.

Esta publicación describe qué funcionalidad es compatible.

Aquí se muestra una muestra de mi servidor WCF que el cliente Metro puede consumir .

También tenga en cuenta que no puede usar WCF síncrono en Metro. Tendrá que usar un contenedor basado en tareas que solo es asíncrono.

Y gracias por tu pregunta. Fui un buen punto de partida para mí :)

experto
fuente
7
Gracias por esto ... eso es de gran ayuda. Es bueno ver una respuesta práctica en lugar de simplemente que se le diga que no se debe / no se puede hacer.
dodgy_coder
1
Puede ser una pregunta estúpida ... pero ¿puede conectarse a localhost usando su muestra o no? La pregunta a la que enlaza muestra los aspectos internos de Visual Studio (lo deduje de la ruta, pero si me equivoco, corríjame). ¿WCF (combinado con localhost) funciona fuera de WCF?
dzendras
1
@dzendras Seguro, funcionará. También funcionará con localhost.
experto
3
Sin embargo, dudo que una aplicación como esta pase la certificación Store.
Ani
6
En todo caso, esta es la regla, creo que podría citarse "3.9 Toda la lógica de la aplicación debe originarse en el paquete de la aplicación y residir en él. La aplicación no debe intentar cambiar o ampliar el contenido empaquetado mediante ninguna forma de inclusión dinámica de código o datos que cambian la forma en que la aplicación interactúa con Windows Runtime, o se comporta con respecto a la política de la tienda. No está permitido, por ejemplo, descargar un script remoto y luego ejecutarlo en el contexto local de su paquete de aplicación ".
Ani
38

Hubo una serie de preguntas como esta al final de una // construcción / sesión a la que asistí. Aleš Holeček, el ejecutivo que hizo una de las sesiones de imagen grande, salió de la audiencia para manejarlos. Incluso si no es un desarrollador de C ++, descargue esa sesión y vea las preguntas y respuestas http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Las aplicaciones de Metro no pueden contar con la instalación de aplicaciones o servicios de escritorio en la máquina. Y las aplicaciones de escritorio no pueden contar con las aplicaciones de Metro en ejecución, ya que pueden suspenderse en cualquier momento. Tienes que empezar a pensar de manera diferente. Escuche a Aleš en este.

Kate Gregory
fuente
6
Esta pregunta exacta parece formularse a las 47:20 en el video.
Pavel Minaev
3
... y uno más a las 55:00. La respuesta, en términos generales, parece ser "no, no puedes hacer eso".
Pavel Minaev
1
@dodgy_coder No estoy seguro de que WCF / TCP (o HTTP) funcione en la misma máquina. Si la caja de arena no le permite conectarse localhostdirectamente a través de un socket TCP, ¿por qué le permitiría hacer lo mismo a través de WCF?
Pavel Minaev
2
Curiosamente, hay soporte integrado para la comunicación entre dos aplicaciones metropolitanas a través de contratos compartidos, pero esto parece ser similar en el uso del portapapeles y para transferir unidireccional desde una aplicación de origen a una aplicación de destino, en lugar de implementar, digamos, dos Protocolo de comunicación de vía.
dodgy_coder
4
Me parece que las aplicaciones LOB Metro de carga lateral no tendrían ningún problema dependiendo de una aplicación o servicio de escritorio instalado. Me cuesta creer que este escenario tan práctico no sea compatible. Con Silverlight, vimos un aumento gradual en las capacidades de interoperabilidad nativa / de escritorio ... Estoy bastante seguro de que algo a lo largo de estos escenarios (canalizaciones con nombre o archivos asignados en memoria, o algo ...) será compatible (con documentos de orientación) en el futuro.
David Cuccia
11

Tenga en cuenta que con Windows 8.1 Update, la comunicación entre las aplicaciones de la Tienda Windows y los componentes de escritorio escritos en C # para .NET 4.5+ ahora es oficialmente compatible con las aplicaciones de carga lateral en escenarios empresariales:

Componentes intermedios de Windows Runtime para aplicaciones de Windows Store de carga lateral

Citar:

Reconociendo que las funciones y reglas críticas del negocio están incorporadas en los activos de software existentes y que las empresas tienen una amplia variedad de escenarios para los cuales el nuevo estilo de aplicación será altamente productivo, la Actualización de Windows 8.1 incluye una nueva característica llamada Componentes Brokered Windows Runtime para carga lateral. aplicaciones. Usamos el término IPC (comunicación entre procesos) para describir la capacidad de ejecutar activos de software de escritorio existentes en un proceso (componente de escritorio) mientras interactuamos con este código en una aplicación de la Tienda Windows. Este es un modelo familiar para los desarrolladores empresariales, ya que las aplicaciones de base de datos y las aplicaciones que utilizan NT Services en Windows comparten una arquitectura multiproceso similar.

Aunque la implementación de este enfoque es un poco complicada al principio, permite una integración profunda en la Tienda Windows y los componentes del escritorio. Solo tenga en cuenta que, por el momento, no pasará la certificación pública de la Tienda Windows.

ig2r
fuente
5

Hay un artículo sobre InfoQ sobre cómo crear aplicaciones Metro acopladas libremente con controladores de protocolo. Esto es algo que ha sido soportado por Windows durante mucho tiempo y uno podría prever que una aplicación de escritorio se registre como un controlador de protocolo y tal vez la aplicación metro pueda comunicarse a través de este mecanismo.

No tengo idea de si esto es posible, pero sería interesante comprobarlo.

tronda
fuente
El artículo dice: "La forma en que puede hacer esto en Metro [saltar a otro flujo de trabajo en una aplicación diferente, porque su aplicación debe ser pequeña y muy enfocada] es aprovechando los protocolos. Para nuestro ejemplo anterior, el protocolo puede verse como "Acme-stock-purchase: // cliente = 123 & stock = XYZ". " - ¿Qué significa técnicamente "aprovechar los protocolos"?
Lumi
El problema con este enfoque es que es solo una forma de comunicación.
experto
3

Christophe Nasarre ha escrito en su blog sobre una forma bastante hacky de hacerlo utilizando archivos locales. El resultado es la comunicación entre la aplicación de escritorio y la aplicación de la tienda de Windows (denominada DA / WSA en el blog), sin tener que cambiar entre la interfaz de usuario de las dos aplicaciones. También escribió en su blog sobre otra técnica menos hacky que involucra a los controladores de protocolo.

Tenga en cuenta que tener una WSA que se comunique con un DA está explícitamente prohibido por los requisitos de certificación de la aplicación de la tienda

Las aplicaciones de la Tienda Windows no deben comunicarse con las aplicaciones o servicios de escritorio locales a través de mecanismos locales, incluidos archivos y claves de registro.

... pero restringe solo los "mecanismos locales". Así que supongo que se puede crear un servicio web para enrutar las comunicaciones.

twj
fuente
3

Si cree que puede realizar una operación cmd manual adicional, puede intentar:

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

CheckNetIsolation.exe está incluido en la instalación de winRT, por lo que no hay nada adicional que instalar.

Lo probé: funciona, incluso después de la actualización del paquete.

Como se muestra en: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Aquí se explica cómo averiguar el ID de paquete para su aplicación: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- la-aplicación-de-una-aplicación-estilo-metro

fgalliat
fuente
Quería poder comunicarme con localhost para una aplicación interna y solo podía hacerlo en las computadoras que no ejecutan VS usando este comando.
adosaiguas
2

Es posible comunicarse en la misma máquina desde la aplicación Metro a la aplicación de escritorio usando el servicio local. He implementado hace algún tiempo una simple "prueba de concepto", cómo omitir el sandbox de WinRT usando el servicio local. Todavía necesita algún tipo de "ingeniería social" o guía directa para instalar el servicio, pero de todos modos, es posible.
Sin embargo, no estoy seguro de las reglas de certificación sobre la comunicación del "servicio local" al agregar dicha aplicación a la Tienda Windows.

Muestra aquí

Por diseño, la aplicación Metro no puede acceder directamente a la PC subyacente, solo utilizando la API de WinRT y las capacidades disponibles. Pero cuando crea un servicio de back-end para acceder a la PC y todos los datos allí, básicamente ya no se ejecuta en la caja de arena.

El único "problema" es que el usuario debe instalar manualmente este servicio de back-end, pero eso no será un problema usando alguna "ingeniería social": el usuario descarga la aplicación Metro "navegador de PC", el usuario puede buscar todas las imágenes, música y videos , usando la API de WinRT, pero la aplicación también muestra un mensaje en la parte inferior: "Descargue nuestro paquete de energía del navegador de PC y explore todo su PC, GRATIS"

El usuario es redirigido a la página web, desde donde el usuario puede descargar el instalador de escritorio clásico que contiene el servicio back-end "navegador de PC" para acceder a archivos en toda la PC del usuario. Una vez que se instala este servicio de escritorio, la aplicación Metro puede detectarlo y usarlo para navegar por toda la PC. El usuario está contento, pero la zona de pruebas de WinRT está comprometida.

Por supuesto, esto no funcionará en tabletas ARM con Windows 8. Con esta solución alternativa, incluso podría ser posible crear clientes de aplicaciones Metro para aplicaciones de escritorio clásicas como antivirus, clientes torrent / P2P, etc.

Martín Suchan
fuente
3
No estoy seguro de por qué necesita mencionar la ingeniería social ... dado que la pregunta original se refiere a una aplicación / servicio de escritorio que habla con una aplicación de metro, se espera que el usuario deba instalar la aplicación / servicio de escritorio por separado. Entonces, ¿qué método de comunicación utilizó entre el servicio de escritorio y la aplicación de metro?
dodgy_coder
0

Tal vez me perdí el punto, pero al activar la capacidad de redes privadas, puedo conectarme a un servidor local en ejecución (http) usando la dirección IP local (no localhost). Esto habilita mi escenario donde una aplicación winrt se comunica con una aplicación de escritorio wpf

Wendelin
fuente