.NET en Windows 8: AppContract, Marketplace y WPF/C# desde un punto de vista de Dev

Question

Estoy bastante excités sobre todas las cosas nuevas que se producen en Windows 8, pero al mismo tiempo un poco preocupado por cómo y si puedo continuar usando el código y los componentes personalizados, ya he construido usando .NET y C# durante mi tiempo Como un desarrollo de Windows. Tengo algunas preguntas mixtas generales sobre esto. Espero que no te importe que los esté juntando en una publicación:

• ¿Windows 8 Store será para aplicaciones de estilo metro y aplicaciones regulares de WPF-desktop? ¿Incluyendo presionar actualizaciones y hacer que las aplicaciones estén disponibles para los empleados de la empresa?

• ¿El nuevo contrato de la aplicación también estará disponible para WPF-Apps? ¿Y AppContract se basa en los servicios WCF con quizás el descubrimiento UDP en la red? ¿Puedo hacer mis propios contratos entre mis propias aplicaciones utilizando el marco del contrato de la aplicación?

• No estoy particularmente preocupado por si WPF será abandonado o no. Puedo vivir sin él. Lo que me preocupa es que si todavía puedo escribir la presentación y el código de la capa de negocios en C# y usarlo como un backend para mis aplicaciones, sin importar el trabajo de frame. . Si todavía puedo escribir lógica en C# y presentarla usando X ui-Framework, soy un desarrollador feliz. Escuché que puedo acceder al trabajo de marco .NET de JavaScript. Pero, ¿qué pasa con los ensamblajes personalizados?

Answer 1

Se ha anunciado que las aplicaciones que no son de metro pueden aparecer en la tienda, pero la tienda solo se vinculará al sitio web del editor, no administrar las cosas de venta/instalación/DRM/etc.

Lo que se ha anunciado hasta ahora es que los contratos son solo para aplicaciones de metro, pero me sorprendería si esto no cambia. Sería una locura para Microsoft no Para permitir que las aplicaciones de escritorio, por ejemplo, agregue comandos al encanto de configuración, admitan playto o imprima a través del encanto de dispositivos, o actúen como fuentes compartidas. Tendremos que esperar y ver dónde dibujan la línea en lo que las aplicaciones de escritorio pueden/no pueden hacer.

Compartir código entre aplicaciones Metro y no metro será muy difícil. Muchos de los conceptos y convenciones centrales son los mismos, pero incluso las cosas básicas como la E/S de archivos dependen de una API totalmente nueva. No hay muchas cosas interesantes con el código que funcione en ambos lados de la cerca. La mejor opción sería definir las interfaces para las cosas de su capa comercial y luego usar la inyección de dependientes para seleccionar dinámicamente las implementaciones de escritorio versus winRT en tiempo de ejecución

Answer 2

• Almacén: no hay información final, pero por lo que la entendí, es solo para aplicaciones de estilo de metro

• Los contratos de la aplicación son algo metropolitano. Conozco un fragmento de código que documenta el uso de las aplicaciones de escritorio (por ejemplo, http://www.heise.de/developer/artikel/winrt-in-klassischen-net-anwendungen-nutzen-1366039.html (lo siento, alemán)), pero no sé si tendrá soporte de Microsoft

• WinRT compila bibliotecas en componentes WinRT. Es posible que pueda reutilizar el código y compilarlos a un componente siempre que no esté utilizando un espacio de nombres que no esté disponible para WinRT

Esta pregunta es pesada para adivinar ya que no hay beta oficial disponible. E incluso entonces no podemos estar absolutamente seguros ...