c# - studio - ¿Cómo se puede comunicar una aplicación Metro en Windows 8 con una aplicación de escritorio de back-end en la misma máquina?
windows 10 developer (8)
En una situación en la que tiene la interfaz de usuario de UI construida utilizando el nuevo estilo Metro de aplicaciones para Windows 8, y desea 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 de metro y la aplicación de escritorio?
Gracias a Pavel Minaev del equipo de Visual Studio, quien ha proporcionado información inicial aquí en un comentario, citó:
Según Martyn Lovell, no hay ningún mecanismo deliberado para eso, y algunos que podrían ser utilizados están restringidos intencionalmente. Los conductos con nombre no están allí, por ejemplo, ni los archivos mapeados en la memoria. Hay sockets (incluidos los sockets de servidor), pero cuando se conecta a localhost, solo puede conectarse a la misma aplicación. Puede usar archivos normales en una de las "carpetas conocidas" compartidas (documentos, imágenes, etc.), pero ese es un truco bastante crudo que necesita un sondeo y es visible para el usuario. - Pavel Minaev comentando sobre este tema
Por lo tanto, al fallar los enfoques normales, estaba pensando en usar servicios web o leer / escribir en una base de datos para lograr que se produzca algún tipo de comunicación, ambas cosas parecen excesivas cuando los procesos se ejecutan en la misma máquina.
¿Lo que intento aquí tiene sentido? Veo la necesidad de que una aplicación de metro sea la interfaz de usuario frontend para un servicio existente que se ejecuta en el escritorio. ¿O es mejor simplemente usar WPF para la interfaz de usuario frontend que se ejecuta en el escritorio (es decir, una aplicación que no sea de metro)?
Christophe Nasarre ha blogged en su blogged acerca de una forma bastante hacky de hacerlo utilizando archivos locales. El resultado es la comunicación entre la aplicación de escritorio / aplicación de Windows Store (denominada DA / WSA en el blog), sin tener que cambiar entre la interfaz de usuario de las dos aplicaciones. También blogueó sobre otra técnica menos hacky que involucra a los manejadores de protocolo.
Tenga en cuenta que tener una WSA que se comunique con un DA está explícitamente prohibida por los requisitos de certificación de la aplicación de tienda
Las aplicaciones de la Tienda Windows no deben comunicarse con aplicaciones o servicios de escritorio locales a través de mecanismos locales, incluso a través de archivos y claves de registro.
... pero restringe los "mecanismos locales" solamente. Entonces, creo que uno puede construir un servicio web para enrutar las comunicaciones.
Es posible comunicarse en la misma máquina desde la aplicación Metro a la aplicación de escritorio utilizando el servicio local. Implementé hace algún tiempo una simple "prueba de concepto", cómo evitar el entorno limitado 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 acerca de las reglas de certificación sobre la comunicación del "servicio local" al agregar dicha aplicación a la Tienda Windows.
Por diseño, la aplicación Metro no puede acceder directamente a la PC subyacente, solo utilizando la API WinRT y las capacidades disponibles. Pero cuando creas un servicio de back-end para acceder a la PC y toda la información allí, básicamente ya no se ejecuta en sandbox.
El único "problema" es que el usuario debe instalar manualmente este servicio de back-end, pero eso no será un problema utilizando alguna "ingeniería social": la aplicación Metro de "PC browser" de descargas de usuario, el usuario puede navegar por todas las imágenes, música y videos , usando la API de WinRT, pero la aplicación también muestra el mensaje en la parte inferior: "Descargue el paquete de energía de nuestro navegador de PC y navegue por toda su PC, GRATIS"
El usuario es redireccionado a la página web, desde donde el usuario puede descargar el instalador de escritorio clásico que contiene el servicio de fondo del "navegador de PC" para acceder a los archivos en la PC completa de los usuarios. Una vez que este servicio de escritorio está instalado, la aplicación Metro puede detectarlo y usarlo para explorar toda la PC. El usuario está contento, pero el entorno limitado de WinRT está comprometido.
Por supuesto, esto no funcionará en las tabletas con ARM de Windows 8. Con esta solución alternativa, incluso podría ser posible crear clientes de la aplicación Metro para aplicaciones de escritorio clásicas, como antivirus, clientes de torrent / P2P, etc.
Estoy portando mi proyecto existente a Win8 en este momento. Consiste en servicio de ventanas y aplicación de bandeja que se comunican entre sí a través de NamedPipes WCF. Como ya sabrá, Metro no es compatible con las tuberías con nombre. Terminé usando TcpBinding para la conexión full duplex.
Esta publicación describe qué funcionalidad es compatible.
here hay una muestra de mi servidor WCF que el cliente de Metro puede consumir.
También tenga en cuenta que no puede usar WCF síncrono en Metro. Tendrá que usar Task contenedor basado en Task que es solo asincrónico.
Y gracias por tu pregunta. Yo era un buen punto de partida para mí :)
Hay un article sobre InfoQ sobre cómo construir aplicaciones de Metro débilmente acopladas con manejadores 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 a sí misma como manejador de protocolo y tal vez la aplicación de metro pueda comunicarse a través de este mecanismo.
No tengo idea de si esto es posible, pero podría ser interesante verificarlo.
Hubo varias preguntas como esta al final de // build / session a la que asistí. Aleš Holeček, el ejecutivo que hizo una de las sesiones de gran visión, salió de la audiencia para manejarlos. Incluso si no eres un desarrollador de C ++, descarga esa sesión y mira el Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Las aplicaciones Metro no pueden contar con aplicaciones de escritorio o servicios instalados 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. Escucha a Aleš en este.
Si cree que puede realizar una operación manual adicional de cmd, 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 más que instalar.
Lo intenté: 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 encontrar el packageID para su aplicación: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
Tal vez no entendí el punto, pero cuando activo la función de redes privadas, puedo conectarme a un servidor local en ejecución (http) usando la dirección IP local (no localhost). Esto permite mi escenario donde una aplicación winrt se comunica con una aplicación de escritorio wpf
Tenga en cuenta que con la actualización de Windows 8.1, 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 los escenarios Enterprise:
Componentes Brokered de Windows Runtime para aplicaciones de la Tienda Windows de carga lateral
Citar:
Reconociendo que las funciones y reglas comerciales críticas están incorporadas en activos de software existentes y que las empresas tienen una gran 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 Brokered Windows Runtime Components for side-loaded aplicaciones. Utilizamos 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 similar de procesos múltiples.
Si bien la implementación de este enfoque es un poco complicada inicialmente, permite una integración profunda entre la Tienda Windows y los componentes del escritorio. Solo tenga en cuenta que, por el momento, no pasará la certificación pública de Windows Store.