Gracias por escuchar los comentarios de la comunidad. Estoy muy emocionado por WinUI 3.0 (Win32 + WinUI + C ++). ¡Se siente como el marco que estábamos esperando! RIP GDI 😉

(Modelo de aplicación Win32) + (WinUI 3.0 UI) + (lenguaje .NET o C ++)

Entonces, ¿esto sería básicamente la interfaz de usuario de UWP, pero sin el ciclo de vida y la zona de pruebas similares a los de un teléfono? Eso parece interesante para las aplicaciones de escritorio, entonces, experimentaré con esto.

Gracias por la actualización y, con suerte, vendrán más actualizaciones a medida que se bloquee el conjunto de funciones inicial de WinUI 3.0 y cualquier nuevo control o función de control que se haya propuesto, que puede convertirse en WinUI 3.0.

Ah, y la documentación sobre cómo funcionará WinUI en Desktop , y diferir de UWP, WPF y Win32 sería muy útil para adelantarse a la innumerable cantidad de preguntas que vendrán.

¡Quizás una buena matriz de lo que se incluye con qué combinación de marcos y API, junto con los diagramas de arquitectura que obtuvimos en Build!

Ustedes son increíbles, ¡gracias por todo!
La sección xplat me alegró el día, especialmente porque Uno está en el radar.

Nuestro enfoque sigue siendo Windows 10 y 8.1, pero escuchamos los comentarios de que algunos de ustedes todavía tienen usuarios y clientes en Win7 y evaluaremos el mercado y las opciones a lo largo del tiempo.

Suponiendo que esta implantación del marco de la interfaz de usuario está diseñada con la idea en mente de la portabilidad, al menos lo suficiente para que su núcleo de la interfaz de usuario (renderizado / entrada) pueda funcionar en cualquier sistema operativo Windows que admita .NET Core 3+, qué limitaciones en Windows 7 habría incluso ¿ser? Parece que la mayoría de las funciones que las personas usan en el escritorio simplemente funcionarían y para las especiales / específicas de la plataforma que no lo hacen, tal vez mantenerlas alejadas de ser parte del sistema central de la interfaz de usuario y mantenerlas en paquetes específicos de la plataforma como (Win10, Win8.1, Win7 Nugets, etc.).

Además, si hubiera un XAML multiplataforma que tuviera la misma apariencia en todos los dispositivos (Win32, Android, iOS y WASM) como se puede hacer con HTML (pero no con Xamarin, lamentablemente), mi empresa lo habría aprovechado hace años.

También me alegro de que consideren esto un "maratón (también un gran juego de Bungie)". Cuanta menos fragmentación haya en el espacio XAML, mejor para todos y tomar muchos atajos te llevará de regreso al punto de partida;)

La documentación sobre cómo funcionará WinUI en el escritorio y se diferenciará de UWP, WPF y Win32 sería muy útil.

¡Estamos trabajando en ello y compartiremos más a medida que se desarrolle!

Suponiendo que esta implantación del marco de la interfaz de usuario está diseñada con la idea en mente de la portabilidad, al menos lo suficiente para que su núcleo de la interfaz de usuario (renderizado / entrada) pueda funcionar en cualquier sistema operativo Windows que admita .NET Core 3+, qué limitaciones en Windows 7 habría incluso ¿ser?

@ zezba9000 WinUI no usa .NET, y no necesariamente tiene que usar .NET Core con WinUI: es un marco nativo construido sobre las API del SO y se basa en la nueva funcionalidad en Win8 / Win10 que no estaba presente en Win7: en algunos casos para funciones principales, no solo funciones complementarias de nivel superior como controles específicos.

La documentación sobre cómo funcionará WinUI en el escritorio y se diferenciará de UWP, WPF y Win32 sería muy útil.

¡Estamos trabajando en ello y compartiremos más a medida que se desarrolle!

Suponiendo que esta implantación del marco de la interfaz de usuario está diseñada con la idea en mente de la portabilidad, al menos lo suficiente para que su núcleo de la interfaz de usuario (renderizado / entrada) pueda funcionar en cualquier sistema operativo Windows que admita .NET Core 3+, qué limitaciones en Windows 7 habría incluso ¿ser?

@ zezba9000 WinUI no usa .NET, y no necesariamente tiene que usar .NET Core con WinUI: es un marco nativo construido sobre las API del SO y se basa en la nueva funcionalidad en Win8 / Win10 que no estaba presente en Win7: en algunos casos para funciones principales, no solo funciones complementarias de nivel superior como controles específicos.

Para compatibilidad con Windows 7, se requeriría que algún tercero construyera su propio renderizador compatible para XAML, así como algún tipo de Shim alternativo para cualquier API de nivel de sistema operativo necesaria.

En este momento no hay idea de si esto es posible; la esperanza es que cuando los bits de WinUI se eliminen del sistema operativo, se coloquen en el proyecto de código abierto de alguna manera, lo que permitirá a otras plataformas proporcionar algún tipo de componente de compatibilidad. Piense en Xamarin, Uno o .Net Core con un representador personalizado.

Es un marco nativo construido sobre las API del SO y se basa en una nueva funcionalidad en Win8 / Win10 que no estaba presente en Win7, en algunos casos para las características principales.

En mi opinión, lo que constituye una "característica central" no sería algo que dependa de las especificaciones del sistema operativo además de la representación y la entrada del curso. Que en esos casos serían capas de abstracción que cualquiera puede extender. En un nivel básico, en teoría, uno debería poder representar la interfaz de usuario con un renderizador de software personalizado y hacer Input con un backend XInput personalizado con un cursor virtual si así lo desea. Si puede hacer ese tipo de modularidad, puede hacer prácticamente cualquier cosa y extender el soporte de la plataforma se vuelve extremadamente fácil (como se hace en los juegos). Pasas un poco más de tiempo en esta área y en el futuro todo requiere mucho menos esfuerzo. Si WPF XAML se diseñó de esta manera, podría haberse tomado y usado en aplicaciones para UWP. De lo contrario, la deuda técnica se convertirá en un bucle sin fin.

Cosas como la compatibilidad con el icono de la bandeja, etc. podrían estar en un paquete de "características básicas de WinUI Windows (Win7-Win10)". Cosas como notificaciones push podrían estar en un paquete de "características extendidas de WinUI Windows (Win8-Win10)".

Espero que tenga sentido.

@mdtauk , @ zezba9000 , todo es teóricamente posible y tenemos mucha experiencia en abstracción de plataformas en el equipo. Como con cualquier cosa, solo se reduce al costo, el cronograma y el beneficio esperado 😊

Además de los costos de desarrollo y prueba (que se extenderían a áreas potencialmente no obvias, por ejemplo, garantizar que todo funcione con tecnologías de asistencia antiguas), también debemos considerar el costo de soporte durante períodos de tiempo prolongados.

¿Espera tener nuevos clientes en Win7 en 2020+? Los comentarios y los casos de uso definidos nos ayudan a priorizar.

Además de los costos de desarrollo y prueba (que se extenderían a áreas potencialmente no obvias, por ejemplo, garantizar que todo funcione con tecnologías de asistencia antiguas), también debemos considerar el costo de soporte durante períodos de tiempo prolongados.

¿Espera tener nuevos clientes en Win7 en 2020+? Los comentarios y los casos de uso definidos nos ayudan a priorizar.

@jesbis No veo mucho beneficio en agregar compatibilidad a Win7 para WinUI 3.0; sin embargo, Linux, Android, iOS, iPadOS y MacOS pueden ser beneficiosos para proporcionar una solución multiplataforma, que no depende de marcos de interfaz de usuario nativos.

@mdtauk
@jesbis No veo mucho beneficio en agregar compatibilidad a Win7 para WinUI 3.0; sin embargo, Linux, Android, iOS, iPadOS y MacOS pueden ser beneficiosos para proporcionar una solución multiplataforma.

Acepta eso. Solo agregaría ensamblaje web, para mí es incluso más esencial que Linux.

¿Espera tener nuevos clientes en Win7 en 2020+? Los comentarios y los casos de uso definidos nos ayudan a priorizar.

No, mi empresa no lo hace. Estaba dando más de un argumento de diseño en un área con la que he visto luchar a XAML en todas sus iteraciones (desde mi perspectiva) pero ya veo totalmente por qué MS no querría pasar tiempo allí. Sin embargo, sería genial si WinUI fuera lo suficientemente capaz para que otros hicieran este trabajo si lo necesitaran (lo que tiende a suceder, me he dado cuenta) sin pasar por un agujero de conejo de las dependencias de Windows, como es el caso de WPF ahora.

Para tener claro lo que a mi empresa le encantaría ver es que el soporte de Android y WASM sea un poco más oficial que UNO (y hace 3 años). Hacemos software de administración que gobierna el estado de una colección de computadoras locales y configuraciones del sistema que generalmente implican una gran necesidad de API de Win32 (UWP nunca funcionaría para nosotros, pero nos gusta la interfaz de usuario debido a errores en tiempo de compilación a diferencia de los sistemas de compilación HTML) y nuestro los clientes + nosotros necesitamos experiencias de interfaz de usuario de navegador de Win32 + Android + que tengan una experiencia y una sensación uniformes. HTML es solo un gran problema, ya que agrega abstracción y complejidad innecesarias que, de lo contrario, no necesitarían estar allí, ya que nuestra base de código principal está en C #.

Espero que sean mejores comentarios para ti.

También sí, WASM es el objetivo más grande que nos gustaría frente a cualquier otra plataforma. ¡¡CON MUCHO!!
Ya que resuelve nuestro problema de Android / iOS / móvil, así como las cosas del portal web.

¡Gracias por escuchar los comentarios!

Desktop + WASM será oro!

¡Vaya, gracias por el saludo, @jesbis! Totalmente inesperado y muy apreciado y respetado. 👍

La discusión sobre Windows 7 distrae un poco, ya que la cantidad de esfuerzo (sin mencionar el costo) causaría un retraso significativo en WinUI 3.0. Windows 7 finaliza su vida útil en enero, y estamos alentando a todos los clientes a actualizar a Windows 10. Es posible que mis clientes no se alineen con otros aquí, pero incluso Windows 8.1 no es una plataforma de interés para nosotros.

Muy contento con la actualización. ¡Los próximos objetivos para WinUI se ven muy brillantes y prometedores! Incluso la sección Xplat fue algo que no esperaba, pero es muy bienvenida. Esperamos poder utilizar las mejoras, así como las ventajas guardadas para WinUI.

Gracias por el equipo por la transparencia.

Me gustaría mencionar la importancia del software de línea de negocio para ayudar a las personas en la solución de varios problemas.

Trabajé durante un tiempo con la herramienta Lightswitch y obtuve una ganancia significativa en el tiempo de construcción. El desarrollo rápido de aplicaciones ha sido muy prometedor para las aplicaciones LOB. Pero con la guerra de patentes en los EE.UU. se toma muy en serio, se tomó el producto para terminar.

Sabemos que tenemos INotifyDataErrorInfo para la próxima entrega. Pero sería maravilloso si WinUI tuviera recursos RAD para futuras entregas como 3.x en adelante.

gracias equipo, no puedo esperar a que llegue el día en que escribas el montaje web. hará mi día, año y década y pondrá a la EM en la parte superior de la pila de tecnología. WinUI + Xamarin + WASM + .NET => ¡¡pura genialidad !!

@jesbis Gracias por esta actualización. Buen equipo de trabajo: +1 :. Entendiendo que aún es temprano, ¿cuándo cree que veremos el hito de WinUI 3.0 creado y los problemas etiquetados en su contra?

¿Cuándo crees que veremos el hito de WinUI 3.0 creado y los problemas etiquetados en su contra?

@shaggygi ¡ Buena pregunta! Lo acabo de crear:

Hito de WinUI 3.0

¡Esto es increíble, chicos!

Pregunta rápida: mover Windows.UI.Composition a Microsoft.UI.Composition, ¿está más cerca de 2.2 o 3.0?
Y en el marco de tiempo para esperar esto, ¿sería esto de 2 a 3 meses o más, cuando 3.0 esté disponible?

En el futuro, cuando hable de años (por ejemplo, "antes de fin de año"), ¿puede aclarar los años calendario y los años financieros de [Microsoft]?
Es fácil tener confusión cuando esto no se indica explícitamente y he conocido ocasiones en las que esto ha llevado a las personas a creer que las cosas sucederán 6 meses antes de lo previsto.

Moviendo Windows.UI.Composition a Microsoft.UI.Composition, ¿está más cerca de 2.2 o 3.0?

@jtorjo esto será 3.0 (como mínimo). Esperamos incluir una versión inicial en la primera versión preliminar de 3.0, pero aún no está garantizado al 100%.

En el futuro, cuando hable de años (por ejemplo, "antes de fin de año"), ¿puede aclarar los años calendario y los años financieros de [Microsoft]?

@mrlacey gracias, ¡lo tendré en cuenta! Todas las fechas que usamos son generalmente de calendario.

@jesbis Eso es un poco triste. Entonces, ¿estás diciendo que es posible que no tengamos Microsoft.UI.Composition en 3.0?

@jtorjo

Esperamos incluir una compilación temprana en la primera vista previa de 3.0 , pero aún no está garantizado al 100%.

A menudo hay muchas versiones preliminares. .NET Core 3 está en Preview 6, por ejemplo.

Nuestro plan es incluir las API de composición en 3.0.

Sin embargo, la parte del marco Xaml será de código abierto antes de la parte de composición.

@jesbis Gracias, ¡suena bien!

¡Hoja de ruta fantástica, gran trabajo!

Como todos aquí, me encanta la transparencia y realmente espero con ansias WinUI 3.0. Para mí, WinUI 3.0 es lo más emocionante desde que se introdujo WPF en 2006.

También tengo clientes que ejecutan Windows 7, pero creo que la compatibilidad con Windows 10 es lo más importante y no gastaría tiempo y recursos en la compatibilidad con Win7. La mayoría de las empresas en las que trabajo están cambiando a 10. Y creo que a finales de 2020 la única empresa que conoceré que todavía usa Windows 7 probablemente será mi dentista. Y si me pide que le escriba una aplicación de Windows, migraré sus PC a Windows 10. :-)

El soporte de WASM en el futuro sería asombroso.

Ayer en una conferencia:

Una pequeña historia para mostrarles a @jesbis y al equipo que los que escribimos y participamos aquí somos solo la punta del emocionado iceberg. :-)

Ayer mismo charlé en una conferencia de desarrolladores en Alemania con algunos desarrolladores de .NET y les hablé de WinUI 3.0 y ellos no lo sabían. Les hablé de la hoja de ruta y me dijeron:

"Guau eso es increible".

Una chica del grupo me preguntó:

"¿Pero puedes contarnos todo esto?"

La miré a ella y a los demás, y luego aproveché la oportunidad para hacer una pausa retórica de

await Task.Delay(3000);

antes de que dije

"¡Demonios, sí! Puedes leer todo esto en GitHub".

Gracias @jesbis y todos los involucrados. Buenos tiempos para ser desarrollador de Windows ❤️

Espero que las aplicaciones propias (¿como Word?) Puedan hacer uso de las capas de WinUI, y los desarrolladores estarán felices de ver que, "Oye, WinUI es una cosa real que puede ejecutar negocios, en lugar de un juguete".
Si ya lo están usando, dígalo en voz alta.

Acrylic para WPF, Win32 y WinUI Desktop.

Ah, y quizás reconsidere la política de Acrylic solo en Windows activo.

Sí, si tiene más de 1 monitor, solo se renderiza en una ventana. Al menos en varios monitores debería funcionar correctamente ...

Estaba pensando en las implicaciones de la experiencia de desarrollo de tener dos conjuntos de controles de IU disponibles en aplicaciones para UWP: cuando tendremos acceso tanto a los controles de WinUI como a los controles de IU heredados, cuando en C # código subyacente, IntelliSense, ya que siempre requerirá que lo hagamos correctamente. elija el espacio de nombres del que debe provenir el control en lugar de presionar Alt + Enter para simplemente agregar using y continuar. ¿Será posible evitar esto de alguna manera?

Una vez que WinUI3 esté disponible para los desarrolladores, los SDK de Windows 10 deberían considerar sugerir el cambio de espacio de nombres para los proyectos que se abren con un SDK compatible instalado. Intente alejar a las personas de los namspaces del sistema operativo.

Acrylic para WPF, Win32 y WinUI Desktop.

Lo que me gustaría ver primero es MS madurando las islas Xaml lo suficiente como para que, como ejemplo, el acrílico en la barra de título se pueda usar para proyectos que no sean de UWP basando su interfaz de usuario en WinUI (consulte el último párrafo de esta publicación ). @ marb2000 es probablemente la persona a quien preguntar sobre esto.

@MartinZikmund Queremos evitar este escenario. Al usar WinUI 3, solo debería tener acceso a los controles del paquete. La idea es que tengamos todo lo que necesita con los últimos y más grandes cambios.

@MartinZikmund
@LucasHaines

Una solución debería ser que puede excluir las referencias de Windows.UI.Xaml.* WinMD de la compilación. Ahora, los objetivos de compilación solo hacen referencia a Unified WinMD, también conocido como. Windows.winmd , agregue una opción en los destinos para también referir WinMD individuales, de esa manera, podemos incluir o excluir las referencias en función de la aplicación que estamos creando.

Si es así, entonces no es necesario cambiar los espacios de nombres, ya que se comporta como un .NET dll y puede funcionar con redireccionamientos de ensamblaje a una versión local dentro del paquete en lugar de los proporcionados por el sistema.

Sé que ese método es específicamente para .NET Framework, pero para UAP, debería haber una solución para este tipo de escenarios. Sé que existe FrameworkDependency en msix/appx manifest. Quizás podamos usar eso para proporcionar al nuevo WinUI Windows.* espacios Microsoft.* unos.

En el lado del desarrollador, tendríamos menos molestias para actualizar nuestras aplicaciones, ¡ya que solo estamos cambiando la referencia y no el código !

¡Preferiría no cambiar el espacio de nombres en absoluto!

Beneficios:

1. No es necesario que cambie el código de un lado a otro.

2. Una vez que se ha estabilizado el código local de WinUI, puede fusionarse nuevamente en la plataforma de Windows, para que las aplicaciones del sistema y las aplicaciones LOB puedan aprovechar las nuevas mejoras, en cada nueva versión de Windows.

3. Por un lado, es un marco de sistema altamente estable con alta compatibilidad como .NET Framework. Y el otro lado es como .NET Core, con cambios a un ritmo más rápido, con todos los beneficios de ambos y ninguno de los problemas.

Acabo de ver una presentación impresionante de Steve Sanderson en la interfaz de usuario Blazor + (no html) envuelta en una aplicación nativa multiplataforma. Aproximadamente 52 minutos en el video. Una visita obligada para los fanáticos de UWP, WinUI y c #. ¡Estoy realmente impresionado con blazor!

https://youtu.be/uW-Kk7Qpv5U

Una cosa que me olvidé de decir en estas discusiones y que encuentro importante es ...
¿Tiene WinUI 3.0 en sí mismo alguna mejora de rendimiento? ¿Se acaba de desacoplar el motor de representación XAML o se están produciendo cambios? ¿Los controles XAML usarán principalmente la composición y, por lo tanto, fuera de subprocesos y controlados por dwm como DirectUI?

El rendimiento de algunos controles y el uso de RAM podrían ser mucho mejores, como ListView / GridView = ItemsControl.

Ves esto en Windows mismo. El menú de inicio de Windows 8 (DirectUI) es mucho más fluido que el menú de inicio XAML de Windows 10.
Intente cargar un GridView con suficiente información, como la página Groove Albums, y las cosas no van tan bien. Esto es algo en lo que iOS y Android se comportan mucho mejor, al igual que winforms, QT.
(En mi opinión, WPF es incluso peor que UWP XAML).

¿Tiene WinUI 3.0 en sí mismo alguna mejora de rendimiento? ¿Se acaba de desacoplar el motor de representación XAML o se están produciendo cambios? ¿Los controles XAML usarán principalmente la composición y, por lo tanto, fuera de subprocesos y controlados por dwm como DirectUI?

El rendimiento es definitivamente algo en lo que queremos seguir invirtiendo, pero no esperaría ninguna mejora para 3.0. El esfuerzo inicial de 3.0 se centra principalmente en desacoplar Xaml para enviarlo como un paquete NuGet y código abierto.

WinUI 3.0 (como UWP Xaml en la actualidad) se basa en la capa de composición y ejecuta gran parte de su renderizado y animación fuera del hilo a través del DWM.

Esto es algo en lo que iOS y Android se comportan mucho mejor, al igual que winforms, QT.
(En mi opinión, WPF es incluso peor que UWP XAML).

A menudo hay una compensación de rendimiento frente a flexibilidad / riqueza al considerar estos escenarios. Las plataformas basadas en Xaml (incluidas UWP y WPF) tienden a tener árboles de objetos de IU más grandes y ricos para cada control: eso proporciona mucha flexibilidad para cambiar el estilo y la UX de cualquier control, mientras que algunas otras plataformas tienden a tener árboles de objetos mucho más planos. que no son tan flexibles pero que a veces se pueden cargar más rápido.

Esa compensación es definitivamente algo en lo que pensamos y tendremos en cuenta para posibles cambios futuros. La flexibilidad adicional de las plantillas de control Xaml complejas no es necesaria la mayor parte del tiempo, por lo que podríamos simplificar los controles para que se carguen más rápido en los casos en que no necesite flexibilidad adicional.

Espero que Microsoft pueda proporcionar un nuevo comctl32.dll y comdlg32.dll basado en WinUI 3.0.

Porque la mayoría de las aplicaciones de Win32 tendrán la experiencia de la interfaz de usuario moderna y ayudará a los desarrolladores a adaptar sus aplicaciones a la interfaz de usuario moderna.

Muchos desarrolladores de Win32 necesitan adaptar varias versiones de Windows. Por lo que no pueden usar directamente WinUI hoy. Es excelente si Microsoft puede proporcionar un método para ayudarlos a reducir la carga de trabajo de modernizar la interfaz de usuario de sus aplicaciones.

Además, espero que Microsoft pueda proporcionar un diseñador XAML para aplicaciones C ++ Win32 que utilizan WinUI.

Kenji Mouri

@MouriNaruto puede usar FileOpenPicker hoy (desde Win32).

@MouriNaruto puede usar FileOpenPicker hoy (desde Win32).

Lo sé, pero espero que todos los controles y cuadros de diálogo comunes modernos se incorporen a Win32.

@MouriNaruto

Técnicamente es posible. Pero los desarrolladores de Windows tienen que recrear no solo los comportamientos exactos de las implementaciones COMCTL y COMDLG , sino también los errores conocidos y desconocidos que existen en el código base.

¡La compatibilidad es nuestro enemigo !

Incluso si lo hacen, para cuando lo completen, ¡cada software que use esas bibliotecas tendrá tiempo suficiente para migrar a WinUI! ¡¡La ironía!! 🤨🤣

@MarkIngramUK

FYI : FileOpenPicker no es un cuadro de diálogo / control nativo de WinRT. Es esencialmente un contenedor de ExplorerFrame que está escrito en DirectUI (desarrollado por ATG Team y basado en DirectX ) y COM .

Técnicamente es posible. Pero los desarrolladores de Windows tienen que volver a crear no solo los comportamientos exactos de las implementaciones COMCTL y COMDLG, sino también los errores conocidos y desconocidos que existen en el código base.
¡La compatibilidad es nuestro enemigo!
Incluso si lo hacen, para cuando lo completen, ¡cada software que use esas bibliotecas tendrá tiempo suficiente para migrar a WinUI! ¡¡La ironía!! 🤨🤣

No creo que sea fácil para muchos proyectos migrar a WinUI sin eso debido a la realidad.

Has dicho "¡La compatibilidad es nuestro enemigo!". Sí, también es una de las razones de mis sugerencias. ¡¡La ironía!! 🤨🤣

Me encantaría tener una versión XAML WinUI de los cuadros de diálogo comunes, incluso si WPF y WinForms tuvieran que optar por usar las nuevas versiones.

El objetivo de WinUI 3 suena muy emocionante y estoy deseando que llegue. Tengo algunas preguntas sobre la distribución / implementación, en el contexto de una aplicación clásica de Win32 que usa WinUI 3

1. ¿Cada aplicación necesita traer su biblioteca WinUI o es posible compartirla entre aplicaciones, tal vez incluso automáticamente a través de los mecanismos de Windows?
2. ¿Será posible vincular estáticamente WinUI?
3. Digamos que tengo que redistribuirlo, ¿qué tamaño tendrá aproximadamente WinUI en MB?

¿Cada aplicación necesita traer su biblioteca WinUI o es posible compartirla entre aplicaciones, tal vez incluso automáticamente a través de los mecanismos de Windows?

Estamos planeando distribuir principalmente WinUI 3 a través de NuGet, que tiene mecanismos para almacenar en caché y compartir paquetes automáticamente; hay más información disponible aquí:

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

¿Será posible vincular estáticamente WinUI?

Esto no es algo que estemos planeando actualmente, ¿tiene un escenario en mente en el que esto sería un beneficio?

Digamos que tengo que redistribuirlo, ¿qué tamaño tendrá aproximadamente WinUI en MB?

Todavía estamos trabajando en cómo se verá el gráfico de dependencia final, pero para las piezas de la interfaz de usuario probablemente será similar a los tamaños de dll de system32 existentes relevantes (decenas de MB).

Estamos planeando distribuir principalmente WinUI 3 a través de NuGet, que tiene mecanismos para almacenar en caché y compartir paquetes automáticamente

Pensé que nuget es solo para desarrollo o ¿me falta algo? Hasta donde yo sé, los paquetes basados ​​en nuget deben ser implementados por cada aplicación individualmente y no se pueden compartir. Es por eso que hay instaladores dedicados para un tiempo de ejecución de dotnet core compartido; de lo contrario, no sería necesario teniendo en cuenta que los paquetes de dotnet core ya están en nuget ...

No debería tener que instalar ninguna herramienta de desarrollo o SDK solo para compartir los paquetes del marco de la interfaz de usuario. WPF y WinForms para .NET Core tenían el mismo problema e invirtieron en la creación de un paquete compartido para que la gente no tenga que instalar el SDK en las máquinas de los usuarios finales , lo que probablemente también valga la pena para WinUI una vez que llegue allí (tal vez incluso consiga incluido en el paquete de WindowsDesktop)

En particular, ya existen opciones de compilación en VS para la implementación dependiente del marco y WinUI debería aprovecharlas para garantizar que los paquetes se compartan. Por supuesto, primero deben proporcionar un paquete que se pueda compartir.

Para las aplicaciones entregadas por Microsoft Store, el contenido del paquete de lanzamiento también debe compartirse automáticamente en la implementación.

Para las aplicaciones win32 implementadas a través de otros medios, está en nuestra lista de tareas pendientes para investigar opciones como la que mencionaste 😊

¿Será posible vincular estáticamente WinUI?

Esto no es algo que estemos planeando actualmente, ¿tiene un escenario en mente en el que esto sería un beneficio?

Creo que necesito aclarar: ¿será posible usar WinUI en un EXE vinculado estáticamente (que vincula estáticamente el VC-Runtime)? Supongo que no debería ser un problema debido a C ++ / WinRT, pero solo quería estar seguro ...

Digamos que tengo que redistribuirlo, ¿qué tamaño tendrá aproximadamente WinUI en MB?

Todavía estamos trabajando en cómo se verá el gráfico de dependencia final, pero para las piezas de la interfaz de usuario probablemente será similar a los tamaños de dll de system32 existentes relevantes (decenas de MB).

Gracias por la información.

Transparencia impresionante por cierto para una empresa tan grande, me gusta mucho.

Creo que necesito aclarar: ¿será posible usar WinUI en un EXE vinculado estáticamente (que vincula estáticamente el VC-Runtime)? Supongo que no debería ser un problema debido a C ++ / WinRT, pero solo quería estar seguro

Esto debería ser posible (en teoría) pero como dijo @jesbis , todavía estamos trabajando en la historia de cómo las aplicaciones no empaquetadas llegarán al marco compartido. Es posible que tengamos que tener un instalador redistado, como cómo lo está haciendo .NET Core.

La discusión sobre Windows 7 distrae un poco, ya que la cantidad de esfuerzo (sin mencionar el costo) causaría un retraso significativo en WinUI 3.0. Windows 7 finaliza su vida útil en enero, y estamos alentando a todos los clientes a actualizar a Windows 10. Es posible que mis clientes no se alineen con otros aquí, pero incluso Windows 8.1 no es una plataforma de interés para nosotros.

Tienes razón. Pero no podemos controlar a mi cliente y hay más del 60% del sistema win7 en China. Y no podemos renunciar a este mercado, por lo que no podemos utilizar ninguna tecnología que no sea compatible con win7.

Los datos son de baidu, consulte https://tongji.baidu.com/data/os

Pero no podemos controlar a mi cliente y hay más del 60% del sistema win7 en China

TBH Me quedaría con .NET Framework 4.8 + WPF si estás atascado en Win7.

Pero no podemos controlar a mi cliente y hay más del 60% del sistema win7 en China

TBH Me quedaría con .NET Framework 4.8 + WPF si estás atascado en Win7.

Pero Win7 Sp1 puede instalar .NET Framework 4.8 y win7 sin sp1 no puede instalarlo.

Requisitos del sistema .NET Framework |

Si ni siquiera tiene SP1, entonces ya ha pasado 6 años del final de su vida útil.

El soporte para Windows 7 RTM sin service packs finalizó el 9 de abril de 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Si desea compatibilidad con Windows 7, debe utilizar una tecnología que ya sea compatible con Windows 7 y no esperar que Microsoft resuelva este problema por usted.

@MarkIngramUK No es que Microsoft me haya resuelto este problema, pero no puedo ayudar a mis clientes que usan win7 sin sp1. No puedo controlar que nuestros clientes usen ningún sistema, pero aquellos que usen win7 sin sp1 abandonarán nuestra aplicación y eso significa que perdimos este mercado. Pero mis competidores que no usan la nueva tecnología pueden soportar win7 sin sp1 y mis competidores ganarán este mercado.

Triste pero cierto, a muchos clientes no les importa la tecnología que usemos, pero les importa que la aplicación pueda funcionar bien en todos sus dispositivos.

Este es el status quo de mi industria, y las conclusiones anteriores pueden no ser adecuadas para otras industrias.

@lindexi, como digo, no se puede esperar que la nueva tecnología se adapte a un sistema operativo que ya tiene 6 años de vida útil. Si desea apuntar a un sistema operativo antiguo, entonces necesita tecnología antigua.

@lindexi Creo que si el cliente no quiere usar tecnología compatible y prefiere algo desactualizado, entonces no puede esperar razonablemente tener una interfaz de usuario moderna. Esos dos requisitos son puramente excluyentes entre sí ...

@MarkIngramUK Triste. Creo que cuando puedo usar la nueva tecnología actual, esta nueva tecnología se ha convertido en tecnología antigua.

@lindexi eso es literalmente lo contrario de lo que está sucediendo. No se puede llamar a la nueva tecnología “tecnología vieja” simplemente porque no se está portando a un sistema operativo antiguo. Si desea compatibilidad con Win7 (sin SP1), use WinForms o MFC o algo.

@MartinZikmund Tienes razón. De hecho, casi ninguno de nuestros usuarios comprende la tecnología informática, incluso win7 y win10 no pueden decirlo. No les importa la tecnología que usemos.

@jesbis Me encantaría ensuciarme las manos con el nuevo WinUI usando C ++. Hice todo lo posible usando UWP y C ++ / Cx en el pasado, pero además de la aplicación PhotoEditor y algunas muestras, siempre terminaba rascándose la cabeza y tratando de encontrar buena documentación, por ejemplo, para vincular XAML con Platform :: Collections y cosas como ese. Esa fue una de las razones por las que volví a cambiar a C # para UWP y Qt para el desarrollo de C ++ en Windows. Por favor, demuestre más amor por C ++.

En mis clientes utilicé una memoria USB (PenDrive) con Windows 10 Media y simplemente la actualicé de Windows 7 a la última versión de Windows 10 de forma gratuita. Obtuvieron el beneficio de un sistema operativo moderno, con antivirus, actualizaciones de Windows, Edge WebBrowser y es compatible con tecnologías GUI desde más antiguas como WinForms, WPF hasta otras más recientes, como UWP y más allá (WinUI). Además, en lugar de Apagar, configuré Windows en Hibernación y enseñé a los usuarios a simplemente presionar el botón de encendido para comenzar a trabajar con la PC, y presionar el Botón de encendido cuando terminara de usar la PC.
También puse una ISO en la red, para instalar / actualizar fácilmente las máquinas.

¡Y tienen la ventaja de tener Candy Crush preinstalado en sus computadoras también!

Opinión

Pensé que las implementaciones de controles de WPF se pueden combinar en WinUI para el soporte de Windows de la versión anterior. (Por ejemplo, Windows 7.) Pero es demasiado difícil para Microsoft hacerlo realidad debido a la política de la oficina, jejeje.

Respuestas

@lindexi
Sé que hoy en día hay muchos usuarios de versiones obsoletas de Windows en China. Pero creo que es necesario abandonar a los usuarios de Windows NT 5.x hoy y sé que es difícil.

@MartinZikmund

Creo que si el cliente no quiere usar tecnología compatible y prefiere algo desactualizado, no puede esperar razonablemente tener una interfaz de usuario moderna. Esos dos requisitos son puramente excluyentes entre sí ...

Tanto la interfaz de usuario moderna como el soporte de la plataforma anterior son necesarios en China si no desea que su trabajo se sirva para minorías. Entonces, uno de mis amigos, un desarrollador chino, transfirió Blink y V8 a Windows XP sin ninguna actualización instalada , muchos desarrolladores lo usan para implementar sus experiencias de aplicaciones modernas. En China, el requisito de versión mínima del sistema operativo es igual a una versión sin actualizaciones instaladas . Por ejemplo, si sabe que el requisito de la versión del sistema operativo de una aplicación de China es Windows 7, le indica que puede usar la aplicación en "Windows 7 RTM" o "6.1.7600.16385 (win7_rtm.090713-1255)". Incluso en el mundo de Android, muchas aplicaciones siguen siendo compatibles con Android 4.4 en la actualidad.

Esta es la razón por la que la mayoría de las aplicaciones creadas por desarrolladores no chinos no pueden ser la elección mayoritaria en China.

PD: Podemos usar el último Visual Studio 2019 para crear aplicaciones para Windows XP RTM sin ninguna actualización instalada , con el último SDK de Windows 10 y el último estándar C ++ 17 o probando C ++ 20 ahora. Debido a VC-LTL (https://github.com/Chuyu-Team/VC-LTL) y YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks).

Nota sobre mi

En la mayor parte de mi tiempo, utilizo la última versión estable de Windows. (Yo uso 10.0.18362 hoy. Estoy usando 19H1 y 19H2.) Pero mis proyectos Win32 diseñados para Windows Vista RTM sin ninguna actualización instalada , y mis proyectos UWP diseñados para Windows 10, versión 1703 sin ninguna actualización instalada o posterior porque el condicional La compatibilidad con XAML se introduce en RS2. (Me encanta XAML condicional. ¿Por qué no existe en Windows 10 Build 14393?)

Kenji Mouri

¡Por favor, considere la posibilidad de quitar el sellado de todas las clases de control de WinUI 3.0!

Según tengo entendido, Microsoft decidió sellar todas las clases de control de UWP, porque JavaScript (que no conoce la herencia) causaba problemas cuando se usaba con clases heredadas. Ahora que JS / HTML está en desuso, ya no es necesario que el nuevo marco de interfaz de usuario siga sellando todas las clases. Un-selaing facilitaría mucho la personalización de los controles de UWP, como siempre fue posible en WPF. También ayudaría mucho al escribir controles o paneles de listas de virtualización personalizados, tener una clase base de virtualización no sellada de la cual heredar. Ni C #, ni C ++ / CX o C ++ / WinRT tienen problemas de herencia. Fue solo el error llamado JS / HTML lo que nos obligó a hacerlo.

Por lo tanto, elimine esta restricción innecesaria al crear WinUI 3.0.

@gisfromscratch ¡ Gracias por los comentarios! Definitivamente queremos apoyar el desarrollo de C ++ (específicamente con C ++ / WinRT).

¿Qué facilitaría el uso de C ++? ¿Ha probado C ++ / WinRT en lugar de CX?

¿Ayudarían más aplicaciones de muestra?

Mencionaste que era difícil encontrar documentación sobre la encuadernación: ¿había otras características específicas que necesitaban una mejor documentación?

¡Por favor, considere la posibilidad de quitar el sellado de todas las clases de control de WinUI 3.0!

@lukasf, esto es algo que probablemente vamos a hacer 🙂 Hay una discusión relacionada en curso en el n. ° 780

@jesbis Tengo que ensuciarme las manos usando C ++ / WinRT mucho más. Acabo de seguir la aplicación de muestra Photo Editor C ++ / WinRT . Pero cuando lee los enlaces proporcionados, como Enlace de datos en profundidad , termina en muchos fragmentos de C # y solo en algunas notas al margen como "Para C ++ / WinRT, cualquier clase de tiempo de ejecución que declare en su aplicación que se derive de una clase base es conocida como una clase componible. Y hay restricciones en torno a las clases componibles ... ". Esta página está dirigida al 95% de C # y solo al 5% de C ++.

@gisfromscratch ¡gracias! Lo tendremos en cuenta mientras trabajamos en la actualización de los documentos para WinUI 3.

Si ayuda, esa página de enlace de datos que mencionó también enlaza a algunas páginas separadas específicamente sobre el enlace de datos con C ++ / WinRT, por ejemplo:

Controles XAML;

Controles de elementos XAML;

También hay una serie de otros temas específicos de C ++ / WinRT en esa sección.

¡Gracias por tu gran trabajo! Muy contento de ver que Xaml Island se eliminó de WinUi 3.0.
Por cierto: Me pregunto si la implementación de bajo nivel de la proyección del componente WinRT parece tener un gran impacto en el rendimiento en el proyecto .NET UWP tanto en tiempo de compilación como en tiempo de ejecución. Dado que WinUi 3.0 está completamente desacoplado de UWP, espero que pueda haber alguna mejora en la implementación de la interoperabilidad de idiomas.

@zenjia XAML Islands no se elimina de WinUI 3. WinUI 3 contendrá las API que permiten que las aplicaciones WPF / WinForms / MFC alojen controles WinUI 3.

He estado tratando de mantenerme al día con el progreso en WinUI. Intenté escribir aplicaciones para UWP en el pasado con C #, pero descubrí que era una batalla cuesta arriba. Pero estoy ansioso por volver a intentarlo después de winui 3.0.

Tengo preguntas sobre la hoja de ruta de winui. Aquí tienes cuatro. Lo siento si se han cubierto en otro lugar. No he encontrado las respuestas, a pesar de muchas búsquedas ... avíseme si hay un foro mejor para hacer este tipo de preguntas.

• ¿Los contenedores .net para los controles nativos también serán de código abierto? No está claro que este sea el github repro que es responsable del lado .Net de winui, considerando que el único código c # que parece encontrar es para pruebas automatizadas. Estoy buscando cosas como Microsoft.UI.Xaml.UIElement pero no puedo encontrar ese código en ninguna parte.

• Cuando lleguemos al lanzamiento de winui 3.0, ¿el modelo de aplicación UWP y el modelo de aplicación win32 ejecutarán el mismo tiempo de ejecución de .Net Core? Nunca he descubierto qué versión de .Net core utilizan las aplicaciones para UWP. Me imagino que es algo que está integrado en Windows y que los SDK de Windows 10 permiten que VS 2019 apunte a la versión correcta del núcleo .Net que está disponible en UWP.

• Una pregunta sobre las islas Xaml. ¿Existe alguna posibilidad de que WPF y UWP puedan compartir el mismo espacio aéreo? No espero tener que lidiar con problemas del espacio aéreo como lo hicimos entre winforms y WPF. Dado que WPF y UWP se basan en direct-X, sería increíble si pudieran compartir píxeles entre sí. Por ejemplo, si tuviera un menú entre bastidores en una cinta (en WPF) que necesitaría superponer una isla xaml de UWP, sería maravilloso si eso pudiera suceder sin problemas. No parece que deba pasar por toneladas de aros para algo así. ... Recuerdo que en los primeros días de WPF, intentaron resolver los problemas del espacio aéreo para las aplicaciones cliente que querían utilizar el control de winforms "WebBrowser". Hicieron una prueba de una función del navegador web llamada "WebBrowser.CompositionMode" y se suponía que permitiría que WebBrowser funcionara bien con WPF. ... Pero creo que esa estrategia finalmente se abandonó. Quizás la interoperabilidad entre UWP y WPF podría ser tan perfecta que incluso podrían compartir píxeles entre sí (a diferencia de winforms y WPF). Una ventaja potencial de esto sería permitir que WPF mejore la funcionalidad de un control de UWP. Por ejemplo, WPF podría superponer una isla xaml con imágenes adicionales de una manera análoga a una capa de adorno. Esto podría resultar útil en caso de apuro.

• ¿Alguna posibilidad de que una aplicación WPF con islas xaml (digamos 50% WPF y 50% WINUI) se compile de forma nativa en ARM64 algún día? La orientación a ARM es posible con aplicaciones que son 100% UWP, y sería bueno que las dependencias de WPF no nos obliguen a abandonar nuestra orientación nativa de ARM64. (La alternativa sería ejecutar la aplicación en emulación x86, pero eso es más lento y limita la memoria disponible que se puede usar).

Es de esperar que todas estas preguntas sean relevantes para la hoja de ruta de winui. Se agradecería cualquier consejo.

¿Los contenedores .net para los controles nativos también serán de código abierto? No está claro que esta sea la reproducción de github responsable del lado .Net de winui, considerando que el único código c # que parece encontrar es para pruebas automatizadas. Estoy buscando cosas como Microsoft.UI.Xaml.UIElement pero no puedo encontrar ese código en ninguna parte.

UIElement no está en WinUI 2, por lo que actualmente no está en el repositorio. Estará en WinUI 3, que aún no se ha lanzado ni es de código abierto, ¡pero estamos trabajando en ello!

Puede ver ejemplos en el repositorio de otros controles nativos expuestos a .NET a través de proyecciones WinRT, por ejemplo, los controles WinUI 2.2 documentados aquí . En su mayoría, no requieren archivos de contenedor preexistentes por idioma, por lo que no encuentra archivos .cs en el repositorio.

@ marb2000 podría comentar mejor sobre las islas / preguntas de escritorio.

P: _ ¿WinUI 3 UWP y Desktop utilizarán el mismo tiempo de ejecución de .NET? _
R: Sí, este es el plan. UWP y Desktop usarán .NET Core 3. Las bibliotecas WinRT administradas usarán .NET Core 3 en lugar de .NET Native.

P: _ ¿WPF y UWP compartirán el mismo espacio aéreo? _
R: Aunque WPF y WinUI (y XAML UWP) parecen similares, no lo son. WPF usa DirectX9 y WinUI / XAML UWP usa Windows.UI.Composition para las necesidades de composición, representación y animación de XAML (además de una versión moderna de DirectX11). Lamentablemente, esto hace que la interoperabilidad sea muy complicada. Su propuesta sobre los adornos de WPF es interesante. En teoría, el adoptante puede crear una ventana emergente para colocar el contenido de WinUI / XAML sobre el contenido de WPF. O puede informar al árbol visual de WPF que se requiere un rediseño, pero todo basado en HWnds.
@dbeavon Esta es una buena propuesta, ¿puede crear una solicitud de función para esto?

P: _ ¿Se compilará una aplicación WPF con Xaml Islands en ARM64? _
R: Si .NET Core 3 para Windows es compatible con ARM64, seguro. Hoy es compatible con ARM32 en Windows. Sin embargo, en Linux es compatible con ARM64. Creo que también está en la hoja de ruta de .NET Core para admitir ARM64 en Windows. Aunque AFAIN, aún no hay fecha. @richlander , ¿alguna novedad?

@ marb2000

P: ¿WPF y UWP compartirán el mismo espacio aéreo?

¿Puede UWP usar Windows.UI.Composition para crear una capa que pueda obtener el renderizado de un mapa de bits de DirectX? Y luego WPF renderiza las ventanas en esta capa como win2d. Quizás pueda compartir el mismo espacio aéreo. Pero es difícil hacer que WPF se renderice en una capa.

@lindexi supongo que podría ser el paraíso: D

¿Puede UWP usar Windows.UI.Composition para crear una capa que pueda obtener el renderizado de un mapa de bits de DirectX?

UWP Xaml tiene varias formas de renderizar mapas de bits DirectX o intercambiar cadenas en Xaml y componerlos con Windows.UI.Composition para que compartan el mismo espacio aéreo, incluidos SurfaceImageSource , VirtualSurfaceImageSource y SwapChainPanel - hay más información disponible aquí:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

También puede insertar un objeto visual Windows.UI.Composition en un árbol de interfaz de usuario Xaml de UWP y dibujar contenido de DirectX en él, por ejemplo, usando ICompositorInterop , ICompositionDrawingSurfaceInterop y ICompositionGraphicsDeviceInterop como se describe aquí:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Esos enfoques deberían funcionar de manera similar con WinUI.

¿Una aplicación de escritorio para UWP podrá hacer referencia a una DLL de WPF / WinForm y abrir una ventana de WPF / WinFrom? Esto me permitiría migrar gradualmente.

@ marb2000 : .NET Core para Windows ARM64 está en nuestra hoja de ruta. Estoy trabajando en un plan para eso ahora.

Con WinUI 3.0, ¿será posible compilar win2d encima?
(por lo tanto, desvincularlo de UWP)
Si es así, ¡sería increíblemente increíble!

Todavía estamos trabajando en detalles sobre la integración de DirectX, pero esperamos que sea posible actualizar Win2D para usar las clases base de WinUI en lugar de las clases base de UWP Xaml.

dedos cruzados: D

lo siento si esto no está en el tema: informes de errores en UWP: ¿agrego un problema en https://github.com/microsoft/microsoft-ui-xaml/ o en otro lugar?

lo siento si esto no está en el tema: informes de errores en UWP: ¿agrego un problema en https://github.com/microsoft/microsoft-ui-xaml/ o en otro lugar?

@jtorjo ¡ gran pregunta! Este repositorio es el mejor lugar para presentar cualquier problema relacionado con:

• las API del marco de la interfaz de usuario de UWP (por ejemplo, Windows.UI.Xaml)
• Diseño fluido
• WinUI

En general, debe haber un vínculo "Enviar comentarios sobre este producto" en la parte inferior de la mayoría de las páginas de documentación en docs.microsoft.com que le indicará la mejor manera de proporcionar comentarios sobre una característica o API específica.

Para la mayoría de los aspectos de UWP, además de los anteriores, será para archivar errores en la categoría Plataforma de desarrollador en el Centro de comentarios, que tiene una serie de subcategorías relevantes.

¿WinUI 3 incluirá el control UWP SemanticZoom? Creo que es el mejor control de todos.

@jesbis ¡Gracias! Acabo de publicar una discusión sobre System.IO

Incluso Microsoft no elimina el soporte de Windows 7 para Office, ¿por qué lo haría WinUI 3? Quiero decir, casi todos los softwares serios tienen soporte para Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Si WinUI no es compatible con Windows 7 ...

Incluso Microsoft no elimina el soporte de Windows 7 para Office, ¿por qué lo haría WinUI 3? Quiero decir, casi todos los softwares serios tienen soporte para Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Si WinUI no es compatible con Windows 7 ...

Es probable que Office deje de ofrecer soporte pronto, ya que el soporte de Microsoft para Windows 7 finaliza muy pronto. Pero está construido sobre una base de código que ya es compatible con Windows 7.

WinUI se construyó sobre Windows 10, por lo que tendría que volver a portarse a Windows 7. El esfuerzo por hacer eso no tiene sentido con el SO que ingresa al final de su vida útil, por lo que la gente tendrá que actualizar a Windows 10.

P: ¿WinUI 3 UWP y Desktop utilizarán el mismo tiempo de ejecución de .NET?
R: Sí, este es el plan. UWP y Desktop usarán .NET Core 3. Las bibliotecas WinRT administradas usarán .NET Core 3 en lugar de .NET Native.
P: ¿WPF y UWP compartirán el mismo espacio aéreo?
R: Aunque WPF y WinUI (y XAML UWP) parecen similares, no lo son. WPF usa DirectX9 y WinUI / XAML UWP usa Windows.UI.Composition para las necesidades de composición, representación y animación de XAML (además de una versión moderna de DirectX11). Lamentablemente, esto hace que la interoperabilidad sea muy complicada. Su propuesta sobre los adornos de WPF es interesante. En teoría, el adoptante puede crear una ventana emergente para colocar el contenido de WinUI / XAML sobre el contenido de WPF. O puede informar al árbol visual de WPF que se requiere un rediseño, pero todo basado en HWnds.
@dbeavon Esta es una buena propuesta, ¿puede crear una solicitud de función para esto?
P: ¿Se compilará una aplicación WPF con Xaml Islands en ARM64?
R: Si .NET Core 3 para Windows es compatible con ARM64, seguro. Hoy es compatible con ARM32 en Windows. Sin embargo, en Linux es compatible con ARM64. Creo que también está en la hoja de ruta de .NET Core para admitir ARM64 en Windows. Aunque AFAIN, aún no hay fecha. @richlander , ¿alguna novedad?

Entonces, ¿nos estamos deshaciendo del sandbox de UWP? ¿Lo que a su vez implica que UWP en su forma actual también desaparecerá, y con ello la caja de arena protegida de la App Store como la conocemos?

Entonces, ¿nos estamos deshaciendo del sandbox de UWP? ¿Lo que a su vez implica que UWP en su forma actual también desaparecerá, y con ello la caja de arena protegida de la App Store como la conocemos?

¡deshacerse del sandbox de UWP sería increíblemente increíble!

Eso definitivamente no significa que UWP vaya a desaparecer. La Plataforma universal de Windows es la única forma de crear de forma nativa para todo el espectro de dispositivos Windows (PC, Xbox, HoloLens, etc.) y es donde Windows centra sus inversiones en plataformas nativas. RE: sandboxing en particular: el aislamiento de contenedores de aplicaciones continúa brindando muchos beneficios importantes para las aplicaciones y los usuarios tanto de UWP como de aplicaciones de escritorio.

Los principales cambios son:

• estamos ampliando el alcance de la plataforma UX (es decir, WinUI) para que también se pueda usar con un modelo de aplicación de escritorio (win32)
• estamos separando WinUI de Windows para que podamos actualizarlo con más frecuencia, hacer que las nuevas funciones sean compatibles con versiones anteriores y abrirlo más fácilmente

Eso significa que para las nuevas aplicaciones, podrá elegir entre UWP y modelos de aplicaciones de escritorio según lo que tenga sentido para su aplicación, y si tiene aplicaciones de escritorio existentes (por ejemplo, WPF, WinForms, MFC), puede actualizarlas gradualmente con aplicaciones modernas. Funcionalidad WinUI usando Xaml Islands.

Entonces, ¿nos estamos deshaciendo del sandbox de UWP? ¿Lo que a su vez implica que UWP en su forma actual también desaparecerá, y con ello la caja de arena protegida de la App Store como la conocemos?

UWP será una de las opciones para crear una aplicación WinUI 3.0. El uso de UWP permitirá que su aplicación se ejecute en Xbox, Hololens, etc.

Pero también puede crear una aplicación Win32 con WinUI 3.0 y acceder a las API de UWP, pero el lugar donde se puede ejecutar su aplicación será más limitado.

@mdtauk @jesbis Estoy totalmente a favor de UWP, pero en este momento:

1. ¡Los tiempos de compilación son increíblemente lentos! (Básicamente, 6 veces más lento que WPF; estoy usando la versión de destino build 1809 - build 17783)
2. Sé que la API de enumeración de archivos StorageFolder no es parte de UWP, pero eso es increíblemente lento. El sandbox de UWP (al menos en el escritorio de Windows) está perjudicando más que ayudando.
3. Claro, la programación asíncrona es divertida, pero en UWP, cuando ocurre una excepción, el código de UWP la devora de alguna manera y luego se interrumpe en el depurador, con todo el contexto de la pila perdido. A veces, tengo el contexto de la pila dentro de la excepción lanzada, pero no siempre.
4. Crear perfiles de código UWP es casi imposible. El evento dotTrace se interrumpe instantáneamente al intentar hacerlo.

(Me tomó más de un mes transferir mi código de WPF a UWP, ya que necesito increíblemente win2d, por lo que no hay forma de que pueda evitar UWP).

@mdtauk @jesbis Estoy totalmente a favor de UWP, pero en este momento:

1. ¡Los tiempos de compilación son increíblemente lentos! (Básicamente, 6 veces más lento que WPF; estoy usando la versión de destino build 1809 - build 17783)
2. Sé que la API de enumeración de archivos StorageFolder no es parte de UWP, pero eso es increíblemente lento. El sandbox de UWP (al menos en el escritorio de Windows) está perjudicando más que ayudando.
3. Claro, la programación asíncrona es divertida, pero en UWP, cuando ocurre una excepción, el código de UWP la devora de alguna manera y luego se interrumpe en el depurador, con todo el contexto de la pila perdido. A veces, tengo el contexto de la pila dentro de la excepción lanzada, pero no siempre.
4. Crear perfiles de código UWP es casi imposible. El evento dotTrace se interrumpe instantáneamente al intentar hacerlo.

(Me tomó más de un mes transferir mi código de WPF a UWP, ya que necesito increíblemente win2d, por lo que no hay forma de que pueda evitar UWP).

Sería útil que esto se publicara en este hilo n. ° 1517 y, con suerte, puede incluir el nombre de alguien del equipo de SDK

@jtorjo

¡Los tiempos de compilación son increíblemente lentos! (más o menos 6 veces más lento que WPF

¿Está utilizando C ++ / WinRT? Si es así, ¿está utilizando encabezados precompilados?

@mdtauk acaba de publicar allí

@MarkIngramUK Es código c #

Cierre: dirija la hoja de ruta y los comentarios alfa a: # 1531

En este momento no hay idea de si esto es posible; la esperanza es que cuando los bits de WinUI se eliminen del sistema operativo, se coloquen en el proyecto de código abierto de alguna manera, lo que permitirá a otras plataformas proporcionar algún tipo de componente de compatibilidad. Piense en Xamarin, Uno o .Net Core con un representador personalizado.

¿Es esto algo realmente en la hoja de ruta o fue solo una suposición?

@mdtauk , @ zezba9000 , todo es teóricamente posible y tenemos mucha experiencia en abstracción de plataformas en el equipo. Como con cualquier cosa, solo se reduce al costo, el cronograma y el beneficio esperado 😊

Quizás abstraerlo de una manera que hiciera posible que un tercero lo hiciera funcionar en Android o iOS sería enorme. Estoy seguro de que la comunidad puede hacer esto. Definitivamente contribuiría a ello.

@andreinitescu Lo siento por la perorata y las quejas, pero solo mis pensamientos de lo que entiendo: mientras que usaré WinUI 3 para reemplazar WPF para Windows / solo cosas de Win32 ... Porque WinUI en Windows usa una API de renderización solo de Windows y no un agnóstico uno, WinUI parece depender de terceros para volver a implementar / fragmentar (ugg) WinUI en otras plataformas (como el proyecto UNO, que es genial, pero como Mono a .NET es una fragmentación innecesaria y una pérdida de tiempo si las cosas solo fueran diseñado correctamente para empezar). En lugar de usar uno portátil como Skia, o crear uno para MS. Tampoco entiendo la necesidad de apoyar al 1% de las personas que no usarán C # con WinUI, lo que convierte a C # en un objetivo de segunda clase en cierto sentido y, lo que es más importante, hace que el tiempo de desarrollo tome mucho más tiempo. Al igual que Android usa Java + post-AOT para muchas aplicaciones principales, Windows debería usar C # + pre-AOT. Porque ahorra tiempo. Después de todo, el 70% de los errores que usan C ++ usan ptrs desasignados.

La falta de comunicación entre los grupos en una empresa para los casos de uso a largo plazo, cuando se convertirá en un problema cada vez mayor cuando lancen su versión de sistema operativo Android para plataformas móviles (que planeo usar) y más personas quieren apuntar a él. con las herramientas de MS ... siento que va a ser otra situación similar a WinPhone7 nuevamente de alguna manera. Windows como término ya no debería estar tan ligado al kernel de WinNT. Un ecosistema es más que una sola plataforma o el marco de una empresa sobre el que se basa.

Lástima que MS no pueda / no quiera hacer lo que Apple hizo hace casi 20 años con el cambio de OS9 a OSX. En eso, se quita la curita moviéndose a un kernel UNIX / LINUX PERO con un emulador / simulador integrado en el sistema operativo para software heredado durante los próximos 5 a 10 años, mientras que la gente migra el software y las herramientas de desarrollo para que se ejecuten de forma nativa. (Piensa lo que quieras de esto pero puedo soñar)