Probablemente sea algo muy lejano, pero Blend necesita una revisión y necesita un flujo de trabajo centrado en el diseño.

El diseñador XAML debe ser sólido y eficaz.

Alguna forma de visualizar la estructura en capas de la página / ventana, especialmente importante con controles elevados.

Formas de visualizar elementos de la interfaz de usuario fuera de una página, como un control / plantilla individual.

Muestra las personalizaciones de control que se realizan para CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, todo dentro del diseñador.

Diseñadores combinados para XAML combinados con WinForms, WPF, MFC y todos los demás Frameworks con los que trabajará WinUI Desktop.

Buenas formas de importar y exportar XAML, para que los diseñadores puedan trabajar en Blend aislados de la aplicación principal y luego entregarlos a los equipos de desarrollo para que los incorporen a la aplicación.

Mejor visualización y listado de los recursos del sistema, así como excelentes formas de extraer esos recursos globales que pueden tener un estilo ligero para anular los valores predeterminados, y la superficie de diseño refleja esos cambios en tiempo real.

Mejores formas de probar diferentes escalas de DPI con aplicaciones que involucran WinForms, MFC, etc.

Plantillas para nuevos controles, diccionarios de recursos de temas personalizados, integra el Fluent Theme Editor, plantillas para combinaciones de aplicaciones compatibles (Win32 MFC con Xaml UI, etc.).

Plantillas para puntos de integración de shell, como selectores de archivos, volantes de bandeja de tareas.

Esos son solo algunos pensamientos ...

Mis pensamientos son los siguientes:

1. MSIX está muy bien, pero sigo usando el viejo MSI para instalar aplicaciones más complejas que requieren características que MSIX no admite. También estoy receloso de usar MSIX debido a lo costosos que son los certificados Authenticode requeridos. (Puedo firmar fácilmente mi código con un certificado autofirmado, que creo que es tan seguro como el que compro a una empresa, pero luego Windows no lo cargará. Sin embargo, Windows aceptará felizmente un archivo MSI autofirmado .) Siempre que pueda usar WinUI 3 desde una aplicación basada en MSI, estoy contento.
2. Un mejor diseñador XAML sería muy apreciado, pero no necesito la complejidad adicional de integrar los diseñadores WinUI XAML y WinForms / WPF en uno. Estoy perfectamente de acuerdo con cambiar entre diferentes pestañas en VS.
3. Como comenté anteriormente , desacoplar el compilador XBF de los sistemas de proyectos C # y Visual Basic sería muy útil. (Sería incluso mejor si se publicara la fuente del compilador XBF, o la documentación suficiente para recrearla, pero no sé qué tan probable es que eso suceda).
4. Mejor soporte para C ++ / WinRT y MIDL 3 en el sistema de proyectos C ++. Actualmente, el soporte del proyecto para usar C ++ / WinRT es frágil y torpe. (Por ejemplo, si cambia el espacio de nombres en el archivo IDL, que a menudo es necesario si hay un punto en el nombre del proyecto que desea usar en los espacios de nombres, ya que la plantilla los convierte en guiones bajos automáticamente, su proyecto no se compilará , y solucionar el problema en mi experiencia requiere mover los archivos *.h y *.cpp un lado, regenerarlos desde cero, copiar el código y luego descargar y editar el archivo vcxproj para arreglar el anidamiento). Por mucho que me gustaría usar algo más moderno y flexible que vcxproj, no puedo hacerlo debido a la gran dependencia que tiene el compilador XBF.

Si surge algo más, me aseguraré de publicarlo aquí. ¡Gracias!

1. Lo que me pregunto aquí es ... Bueno, ¿tendré que usar el prefijo del espacio de nombres como < winui: Listview o < controls: listview o lo que decidan los desarrolladores? Creo que sería mucho mejor, si es posible, usar la misma experiencia que ahora, solo El prefijo está bien y es increíble, solo con unos pocos controles. Pero cuando comienzas a usarlo por todas partes, esto hace que la lectura de XAML sea una pesadilla y muy.
   No tiene sentido usar un prefijo de espacio de nombres, ya que no será posible usar Windows.UI.Xaml.Controls y WinUI será la opción predeterminada.

2. En este momento ni siquiera uso el diseñador XAML. Literalmente desactivo en la configuración. XAML Designer es lento y necesita un mejor soporte. Fue bueno para WPF, pero no para UWP, especialmente si desea hacer un diseño receptivo, manejar páginas, mostrar datos, etc.
   Esta es probablemente una retroalimentación para el futuro lejano, pero creo que es una buena retroalimentación para mirar. El diseñador de WPF es mucho más rápido.
   ¿Es esto por sandbox o qué?

3. Sería interesante una herramienta para realizar una migración. Especialmente porque puede tener algunos problemas de compatibilidad con los controles actualizados de WinUI 3.0, como ScrollViewer. Entonces, si hay una herramienta, debería al menos mostrar posibles advertencias en estos controles actualizados / reescritos.

1. Necesitamos un editor de código xaml robusto con IntelliSense separado del diseñador.
   La mayoría de las veces solo escribo código xaml como C #. Actualmente, el editor de código es lento y frágil, explicado en mi comentario anterior . La experiencia IntelliSense también es bastante simple. Sin información de documentación rápida, sin cambio de nombre de miembros.
2. El soporte de datos de diseño para x:Bind puede ser bastante difícil, ya que estoy escribiendo un ayudante complejo en enlaces de funciones. Pero las cosas pueden mejorar si las funciones integradas de xaml pueden reemplazar algunos ayudantes.
3. Quiero combinaciones mucho más libres de modelo de empaque para mis aplicaciones. Puede que no esté relacionado con el tema, pero no puedo encontrar ningún lugar para enviar comentarios al equipo del modelo de la aplicación.

TL; DR Quiero un modelo de aplicación que admita la coexistencia de instancias arbitrarias . Incluso la misma versión se puede ejecutar con un conjunto de opciones / datos diferentes, como las colmenas de Visual Studio. Actualmente, la única solución parece ser xcopy.

¿Alguien puede decirme cómo colapsar esto?

Primero, también estoy usando la aplicación que estoy desarrollando a diario (y uso >> depurar la mayoría de los días). Así que hacer que la construcción de desarrollo coexista con la construcción estable me ayudará mucho. Actualmente tengo que aumentar el número de versión, empaquetar un debug msix, actualizar la versión del paquete instalado para depurar.
Durante las diferentes fases de depuración, querré una capacidad diferente. Para datos complejos del mundo real, quiero que la instancia de depuración comparta los datos con una estable. Sin embargo, para datos falsos arbitrarios, quiero aislamiento. En teoría, esto se resuelve accediendo a los datos usando el selector de carpetas, pero lamento mucho que SQLite en UWP no lo admita, y no hay otro motor ACID integrado que yo sepa.

Ah, y otra cosa. Realmente, _realmente_ agradecería si se pudiera hacer algo sobre cómo vcxproj requiere el uso de packages.config para las referencias de paquetes NuGet. WinUI se distribuye como un paquete NuGet, al igual que C ++ / WinRT y otros componentes clave. Realmente no me gusta usar packages.config. PackageReference es mucho más eficiente (y no da como resultado una compilación rota si mueve vcxproj a un directorio diferente). En realidad, funciona cuando se usa desde un vcxproj, siempre que el destino de restauración se ejecute en el momento adecuado. (Esto se debe a que los objetivos de vcxproj importan indirectamente la maquinaria de restauración de PackageReference para proyectos que no pertenecen al SDK C #). He escrito un conjunto de objetivos que ejecutan automáticamente el objetivo de restauración cuando el conjunto de elementos de PackageReference ha cambiado, ya que VS no hará esto sí mismo (todavía). Desafortunadamente, el sistema NuGet no sabe nada sobre esto y, como tal, intenta agregar un archivo packages.config cuando agrego una plantilla de archivo C ++ / WinRT. Esto causa todo tipo de estragos, lo que resulta en el lanzamiento de una excepción y un archivo de proyecto roto. No estoy seguro de cuál es la mejor manera de resolver esto, pero realmente agradecería que al menos pudiera examinarse antes de que se lance WinUI 3. ¡Gracias!

Sería bueno que WinUI admita el nuevo proyecto sdk: Microsoft.NET.Sdk o MSBuild.Sdk.Extras .
Los archivos csproj de estilo antiguo son difíciles de mantener. Y no podemos usar múltiples TargetFrameworks con él, lo que podría ser útil para la migración a WinUI.

¿Por qué no hay soporte para F #?

¿Debería discutirse aquí la funcionalidad de Azure DevOps y Visual Studio App Center?

Como @vitorgrs , prefiero los controles nativos sin prefijo de espacio de nombres, agrega "ruido" al código. Y ayuda a ver cuáles son controles nativos y cuáles son de terceros.

Una herramienta de migración estaría bien, por supuesto. Si funciona con los grandes proveedores de terceros (Telerik, DevExpress, ...) eso ya sería una gran cosa.

Plantillas

¿Existe interés o necesidad de que las versiones anteriores de las plantillas XAML de UWP permanezcan en el flujo del nuevo proyecto VS?

Por mi parte, no es necesario guardar las plantillas. ¿Pero podría ser que UWP tiene un Control que no está en WinUI? Si eso pudiera suceder, entonces esta podría ser una razón válida para crear una aplicación UWP tradicional y migrarla a WinUI cuando el Control requerido esté allí. Entonces es posible que necesite la plantilla.

Quizás también sea confuso para los desarrolladores si ha creado una aplicación y ya no puede crearla con la última versión de Visual Studio.

Pero personalmente, no tengo interés en mantener las plantillas

¿Cómo podemos ayudarlo a ser más eficiente o exitoso con respecto a las plantillas y componentes en Visual Studio?

Para mí, esto se ve muy bien para UWP. Ahora quiero ver lo mismo para Win32. :)

¿Es útil este recorrido y le gustaría ver más de esto a medida que los escenarios toman forma?

Sí definitivamente. Este recorrido es muy útil para comprender cómo podría y debería ser el futuro. Me gustaría ver más de esto.

Migración

¿Sería beneficioso si proporcionáramos una herramienta de migración que automatizara los pasos 1-3?

Definitivamente. Quizás una pequeña extensión de Visual Studio sería una gran opción para esta migración. También puedo pensar en algo como un "Analizador de compatibilidad de WinUI" que da como resultado lo que se puede migrar y lo que no. Algo similar al analizador de portabilidad .NET.

¿Qué bibliotecas está utilizando fuera del conjunto de control nativo de Windows 10?

Por lo general, Telerik DataGrid y Community Toolkit

¿De qué formas podemos ayudar con la migración en las que actualmente no estamos pensando?

Si abre una aplicación para UWP en Visual Studio que tiene una versión anterior al SDK de Win que ha instalado, Visual Studio la migra automáticamente. Quizás también debería pensar en algo así para la migración de WinUI. No estoy seguro, pero es algo a tener en cuenta. Especialmente cuando Visual Studio ya no tiene las plantillas normales de UWP, podría resultar confuso para los desarrolladores tener una aplicación que no se puede crear con una plantilla.

Otros

Como ya se mencionó en otros comentarios, creo que es hora de cambiar a archivos .csproj de estilo SDK.

agregue plantillas winui 3.0 a windows template studio.

WinUI en aplicaciones de escritorio

WinUI en el escritorio permitirá a los desarrolladores utilizar la biblioteca de la interfaz de usuario de Windows en un modelo de aplicación de escritorio. @ marb2000 está trabajando en una publicación de discusión más detallada en las próximas semanas. Siéntase libre de usar este hilo hasta entonces para sugerencias.

Como desarrollador de .net, esta es la parte que más me interesa.

Plantillas

• ¿Existe interés o necesidad de que las versiones anteriores de las plantillas XAML de UWP permanezcan en el flujo del nuevo proyecto VS?

Dependiendo de la cantidad de plantillas. Si el número es bajo (por ejemplo, solo la "Aplicación en blanco (Windows universal)" por idioma, por lo que 1 en el caso de c #), el ruido es bajo y se puede admitir. Pero si se trata de más de unas pocas plantillas, no las incluya de forma predeterminada y agregue un componente de instalación VS opcional para agregarlas.

• ¿Cómo podemos ayudarlo a ser más eficiente o exitoso con respecto a las plantillas y componentes en Visual Studio?

Mantenga una plantilla en blanco real sin andamios (mejor para tutoriales). Eche un vistazo a lo que está haciendo asp.net core, hay muchos cambios que han realizado en su nueva experiencia de proyecto. Básicamente, eliges una plantilla genérica "Aplicación (UWP WinUI)", luego una segunda pantalla, específica para tu modelo de aplicación, te permite elegir entre diferentes plantillas. Utilice este paso para elegir también la versión de plataforma mínima y de destino (por lo que no hay ningún paso adicional). Puede agregar una opción para crear el proyecto de empaquetado de la aplicación directamente, por ejemplo.

También brinde un buen soporte para los componentes en la caja de herramientas entre proyectos. Los nuevos controles deben mostrarse inmediatamente en la caja de herramientas, agrupados por proyectos. Quizás soporte para iconos de diseñadores para ayudar a distinguirlos.

• ¿Es útil este recorrido y le gustaría ver más de esto a medida que los escenarios toman forma?

sí

Ayuda de idioma

• ¿Sería beneficioso si proporcionáramos una herramienta de migración que automatizara los pasos 1-3?

Una buena documentación (una página con pasos claros) debería ser suficiente. Si todo se puede hacer desde VS sin editar el csproj a mano, sugiero que solo agregue una página de documentación que describa los pasos.

Si decide (y espero que lo haga) cambiar al nuevo formato csproj, sin duda será necesaria una herramienta de migración, ya que la migración requerirá editar el archivo csproj.

embalaje

MSIX es el método de empaquetado moderno para todas las aplicaciones. Para WinUI en Win32, ¿deberíamos admitir ClickOnce? ¿Para qué otros métodos de embalaje deberíamos incluir soporte? Especialmente para WinUI en Win32

Compare las diferencias entre la implementación de clickonce y msix:

1. la función del instalador de aplicaciones no ofrece la misma experiencia en versiones anteriores de Windows
2. MSIX requiere un paquete firmado válido (interno o público). Clickonce admite paquetes autofirmados.
3. el modelo de paquete tiene algunas limitaciones, principalmente causadas por el entorno aislado (sin acceso a datos de aplicaciones locales, por ejemplo, sin operación elevada).

Para mí, el problema más molesto es el 2. Por lo general, tenemos aplicaciones que hacen clic una vez que se implementan internamente con computadoras que no están registradas en un dominio. Entonces, para este tipo de aplicaciones, será necesario que firmemos el paquete con un certificado de firma público válido.

Es difícil anticipar todas las diferencias entre estos dos marcos, ya que el formato de empaque de Appx a menudo solo se anuncia para aplicaciones dirigidas a la Tienda, y cuando vemos limitaciones, no siempre sabemos si se aplican también al formato de distribución web.

• Experiencia de diseñador

Actuaciones, performances, performances y soporte para grandes soluciones con muchos proyectos.

¿La versión WinUI del SDK de Windows 10 y el diseñador WinUI Xaml se convertirán en código abierto?

¿Podremos publicar solicitudes para el flujo de trabajo de tiempo de diseño y la experiencia?

¿Seguirá el SDK una cadencia de lanzamiento similar a la de los lanzamientos nuget de WinUI?

Algún dolor adicional:
mejorar la experiencia de depuración de mezcla administrada y no administrada.
Actualmente, cuando ocurre una excepción en el código no administrado, COMException se muestra en el sitio de depuración administrado. Las cosas pueden empeorar si la pila de llamadas cruza el límite administrado / no administrado más de una vez.
En comparación con WPF, la pila de llamadas administradas siempre está disponible y la excepción lanzada lleva una cadena que es útil para la depuración.
Sé que el mundo no administrado y el modelo COM no son tan convenientes como administrados. Pero al menos, cuando el marco arroja una excepción (HResult erróneo), quiero la información necesaria para ubicar la línea de código del repositorio

Dependemos en gran medida de ClickOnce, por lo que sería bueno brindar soporte a corto plazo. Estaríamos dispuestos a migrar a MSIX, pero después de que se ofrezcan características similares.

En cuanto a las plantillas, sería bueno tener una que proporcione una interfaz de usuario estándar y un código para NavigationView y navegación.

Gracias

Dependemos en gran medida de ClickOnce, por lo que sería bueno brindar soporte a corto plazo. Estaríamos dispuestos a migrar a MSIX, pero después de que se ofrezcan características similares.

En cuanto a las plantillas, sería bueno tener una que proporcione una interfaz de usuario estándar y un código para NavigationView y navegación.

Gracias

La estructura y los patrones de "shell" de la aplicación más comunes deberían estar disponibles como plantillas para que los desarrolladores puedan empezar a trabajar rápidamente. Las aplicaciones de origen de Microsoft deben ser ejemplares en estos diseños y actuar como las mejores prácticas en términos de comportamiento, coherencia y cumplimiento de las normas de diseño de la interfaz de usuario para Fluent Design y WinUI.

@shaggygi @mdtauk
Para la estructura y los patrones de "shell" de la aplicación más común "y" En cuanto a las plantillas, sería bueno tener una que proporcione una interfaz de usuario estándar y un código para NavigationView y navegación ". Existe Windows Template Studio, que es mantenido y desarrollado tanto por Microsoft como por la Comunidad. Para citar su introducción:

Windows Template Studio (WTS) es una extensión de Visual Studio 2017 y 2019 que acelera la creación de nuevas aplicaciones de la Plataforma universal de Windows (UWP) mediante una experiencia basada en asistentes. El proyecto de UWP resultante es un código legible y bien formado que incorpora las funciones más recientes de Windows 10 al tiempo que implementa patrones comprobados y mejores prácticas.

@ Felix-Dev, ¿habrá eventualmente plantillas WPF además de UWP?

@shaggygi ¡ Puede haber buenas noticias para ti! Vea este hilo : Si bien aparentemente no hay nada garantizado en este punto, aparentemente se está explorando la idea de proporcionar plantillas específicamente para proyectos de WPF. Como se indica en el hilo vinculado, hubo una sesión de adelanto no pública llamada "Windows Template Studio - WPF Edition" alojada en Build 2019.

Estamos usando C ++ / WinRT. No usamos el diseñador xaml o la encuadernación en este momento. Pero crearemos controles en tiempo de ejecución y les aplicaremos estilo posiblemente a través de UWP xaml. También necesitaremos diálogos y ventanas secundarias sin modo con islas xaml, incluidas ventanas de acoplamiento / flotantes, etc.

Intenté escribir XAML para mi aplicación C ++ y la experiencia fue dolorosa.

Tuve que agregar muchas propiedades del proyecto que no están documentadas y algunos otros trucos para generar todo correctamente y empaquetarlo correctamente.

Por ejemplo:

• Al crear un proyecto para almacenar mis páginas XAML, tuve que agregar <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> y <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> , dos propiedades del proyecto que están completamente indocumentadas y solo se resuelven inspeccionando el código fuente de la nueva Terminal.
• Tuve un críptico "No se pudo crear una nueva vista porque la ventana principal aún no se ha creado" hasta que creé y usé una clase de aplicación, que no hay forma de hacerlo en VS excepto crear una página normal y entrar en las propiedades de la XAML en VS y cambiarlo a una definición de aplicación, luego ajustar el MIDL, el código fuente y el archivo XAML.
• Agregué el paquete Microsoft.Toolkit.Win32.UI.XamlApplication NuGet para crear mi clase de aplicación y no pude cargarlo hasta que también agregué Microsoft.VCRTForwarders , nuevamente encontré esto al inspeccionar la fuente de la Terminal, no hay ninguna indicación sobre ninguno de los paquetes en ninguna parte.
• Los PRI no se fusionaban en uno hasta que agregué algo en el archivo .wapproj, por lo que no pudo encontrar mi recurso XAML.
• El XBF no funcionaba hasta que agregué <DisableEmbeddedXbf>false</DisableEmbeddedXbf> que sorprendentemente deshabilita XBF incrustado en lugar de habilitarlo. El único error que tuve fue un error de análisis XAML sin nada que me indicara que los archivos XBF no estaban funcionando.
• maxVersionTested en el manifiesto de mi aplicación se ignoró por completo hasta que lo cambié todo a minúsculas, a pesar de que las instrucciones indicaban que debía usar la versión de caja camel: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecomment -511173811

Además, C ++ / WinRT también estaba siendo un dolor de cabeza:

• Cada vez que ejecuté una compilación incremental, tenía un [msg]redefinition [context]: MyClass para mis clases personalizadas, lo que me impedía compilar y no desaparecía hasta que ejecuté una compilación limpia que, debido a los encabezados de C ++ / WinRT, lleva años. Ese problema de alguna manera desapareció mágicamente a mitad de camino.
• Ahora, cuando ejecuto compilaciones limpias, aparece un error sobre la falta de encabezados. Al presionar el botón de construcción por segunda vez, vuelve a funcionar.
• Tuve que escribir mi propia clase AppT<> debido a un código incorrecto de C ++ / WinRT. La aplicación Terminal y la muestra de islas XAML hacen lo mismo, como si fuera algo que los usuarios tendrían que hacer en lugar de solucionar el problema raíz.
• Cambiar cualquier cosa en los archivos MIDL da como resultado errores de compilación hasta que hago una compilación limpia.

Incluso entonces, todavía no funciona sin empaquetar incluso cuando agrego activatableClass cosas al manifiesto de mi aplicación (algo sobre no poder encontrar el recurso XAML, como cuando no había combinado los PRI), lo cual es importante para que mi aplicación sea compatible.

Migración

La automatización para los pasos 1-3 es definitivamente útil, especialmente porque cambiar el nombre de los espacios de nombres en cientos de archivos requiere mucho tiempo y es propenso a errores. Además de eso, un analizador de compatibilidad sería bueno al igual que el .net framework> .net core, que crea un informe sobre qué tan compatible es el código base actual y anota todos los posibles cambios necesarios.

Estampación

Como otros ya han dicho, sería bueno un editor con más funciones. La mayor parte del tiempo aquí, en el trabajo, XAML se hace a mano y se usa principalmente al diseñador como guía sobre el esqueleto preliminar de cómo se ve la aplicación. Intellisense y las refactorizaciones inteligentes serían realmente útiles, QoL cosas como CTRL + R + R para cambiar el nombre de las cosas (por ejemplo, propiedades de dependencia o incluso la etiqueta), por ejemplo, especialmente cuando tiende a tener muchos UserControls y también GoTo Implementación y referencias. El soporte del analizador Roslyn también sería muy bueno.

Para ampliar las mejoras en el espacio de nombres. Sería bueno si de alguna manera fuera posible tener controles personalizados sin prefijo más fáciles de hacer sin agregar un nuevo XmlnsDefinition s al espacio de nombres predeterminado, ordena el marcado imo y solo necesitaría prefijos cuando se encuentran controles ambiguos como cómo funcionan las clases, esto también encajaría muy bien con la implementación de GoTo. Normalmente, el nombre del control y tal vez pasar el cursor sobre él para mostrar el espacio de nombres completo sería suficiente para saber de dónde viene, normalmente tampoco usarías alias de espacios de nombres en el código C # a menos que sea necesario.

Sobre todo en herramientas, sería bueno si se comportara como el Editor de C # para hacer que las refactorizaciones sean menos frágiles o una molestia y navegar por el marcado más fácil. Aparte de eso, en cuanto al lenguaje XAML en sí, la disminución de la verbosidad también sería un buen ejemplo, como el estilo, como se discutió en # 62 y # 279.

Para ampliar las mejoras en el espacio de nombres. Sería bueno si de alguna manera fuera posible tener controles personalizados sin prefijo más fáciles de hacer sin agregar un nuevo XmlnsDefinition s al espacio de nombres predeterminado, ordena el marcado imo y solo necesitaría prefijos cuando se encuentran controles ambiguos como cómo funcionan las clases, esto también encajaría muy bien con la implementación de GoTo. Normalmente, el nombre del control y tal vez pasar el cursor sobre él para mostrar el espacio de nombres completo sería suficiente para saber de dónde viene, normalmente tampoco usarías alias de espacios de nombres en el código C # a menos que sea necesario.

Me gustaría pensar que la versión WinUI 3.0 del control de página eliminaría la necesidad de usar un prefijo para esos controles. Supongo que esto sería algo a nivel de SDK.

¿Es posible no cambiar los espacios de nombres cuando se usa WinUI?

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 hay necesidad de 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 de los desarrolladores, 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 el código local de WinUI se ha estabilizado, 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.

No creo que sea necesario proporcionar una herramienta de transferencia. Es un cambio único, razonablemente fácil con Buscar y reemplazar, y la cantidad de instancias será bastante baja.

También encontré más problemas:

• Después de agregar recursos a la clase App , mi XAML no pudo encontrarlo hasta que agregué esto, nuevamente encontrado en la aplicación Terminal y sin mucha idea de lo que realmente hace:
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• La construcción se romperá completamente al azar con un error similar a cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication y la única forma de hacer que el proyecto vuelva a construirse es hacer una construcción limpia.
• No puedo ejecutar la aplicación configurando directamente vcxproj para el exe principal como proyecto de inicio, tengo que iniciar manualmente la salida de appx sin empaquetar en bin\x64\Debug\AppX y luego inyectar un depurador desde dentro de VS, o configurar el paquete de la aplicación como proceso de inicio.

Cosas relacionadas en el escritorio de Windows: .NET Community Standup - 25 de julio de 2019 si está interesado.

Hace mucho tiempo que WinForms, desarrollador de WPF aquí con algo de experiencia en UWP. Aquí están mis 2 centavos:

Migración

• Es imprescindible disponer de una herramienta para migrar aplicaciones UWP existentes a WinUI.
• Una herramienta para convertir controles WinForms o WPF en controles WinUI en una aplicación existente sería más que increíble. Al convertir los controles, me refiero a cambiar las referencias en el contenedor a los controles individuales.
• Una herramienta para migrar Xamarin Forms a WinUI para permitir la conversión de una aplicación móvil a Windows.

Estampación

• ¡El editor XAML actual es terrible! Debe usar el lienzo del editor de texto normal y proporcionar las características de Roslyn para que se apliquen al modelo de objetos XAML para una mejor intellisense y refactorizaciones.
• Hasta que Visual Studio sea de 64 bits, el editor XAML debe ser una aplicación independiente de 64 bits en segundo plano. Constantemente tengo que reiniciar VS 2017 y VS 2019 para detener el error de memoria insuficiente cuando trabajo con una gran cantidad de XAML.

Plantillas

• Necesitamos estas plantillas de proyectos

  • NavigationView WinUI
  • NavigationView WPF
  • Cinta WinUI
  • Cinta WPF
  • WinForms de cinta

• Necesitamos estas plantillas de página / ventana

  • Página del controlador de medios
  • Página del navegador
  • Ventana de diálogo
  • Ventana sin bordes
  • Ventana flotante

• Necesitamos plantillas de control

  • Vista de cuadrícula de datos encapsulados
  • Vista de datos secundarios encapsulados

Estos dos últimos trabajarían juntos para crear ventanas sencillas de Master-Detail.

todas estas plantillas y páginas, etc. ya se están haciendo en el proyecto de Windows Template Studio, ¿por qué no seguir la misma ruta en lugar de recrearlo todo?

Archivo de proyecto de estilo SDK
Uno de los aspectos más importantes que me gustaría ver, como muchos otros también han mencionado, es la compatibilidad con el nuevo formato de archivo de proyecto de estilo SDK para aplicaciones UWP y "Desktop XAML".

Migración entre modelos de aplicaciones XAML de escritorio y UWP
Si comenzamos a crear una aplicación "Desktop XAML", ¿a qué distancia estará de una aplicación para UWP? ¿Será trivial convertirla en una aplicación para UWP más adelante si nos damos cuenta de que nos mantuvimos dentro de las limitaciones del entorno limitado de UWP? O si comenzamos a crear una aplicación para UWP y nos damos cuenta de que necesitamos más, ¿será fácil convertirla en una aplicación "Desktop XAML"?

Soy compatible con Template Studio.

Soy compatible con Template Studio.

¿Template Studio admite proyectos XAML C ++?

Lo que está haciendo Template Studio debería ser parte de WinUI SDK IMO

Lo que está haciendo Template Studio debería ser parte de WinUI SDK IMO

¡Debería ser parte de Visual Studio IDE IMO! 😎

chicos, el punto es que el estudio de plantillas de Windows está haciendo todo en uno para la creación de proyectos de UWP, así que, teniendo esto en cuenta, si falta algo como el soporte xaml c ++, deberíamos considerar agregarlo a estudio de plantillas de Windows, creo que será más rápido y más eficiente si todas las nuevas innovaciones en proyectos de uwp permanecen en un solo proyecto.

Deje que haya algún método para usar la capa inferior de la pila de WinUI 3 directamente sin XAML o incluso MVVM. Esto es especialmente útil para el software C ++ de gran hierro existente que ya tiene algún tipo de arquitectura MV-cualquiera que sea en su base de código. Solo quieren algo mejor que HWND + GDI.

Y, por favor, haga que la gente piense que WinUI 3 no es un juguete, realmente puede soportar softwares serios .

@ be5invis Estoy completamente de acuerdo. La única solución en este momento es XamlDirect, pero está más dirigida a los desarrolladores de middleware.

Ya puede crear contenido manualmente con Xaml Islands. Simplemente haga que DesktopWindowXamlSource funcione y se adjunte a una ventana, luego cree y organice / diseñe controles en el código.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK Es posible que necesiten algo más "completo", como reemplazar CreateWindow con funciones de WinUI.

Por el bien del diseño, realmente me gustaría que las futuras plantillas de WinUI WPF tuvieran soporte para expandir el contenido de una página en la barra de título como las aplicaciones UWP actuales. En este momento, con la solución de islas XAML existente, simplemente hospedamos controles dentro de una ventana de WPF / WinForms en lugar de una vista moderna.

@LucasHaines La lista de los lenguajes que planeamos admitir con WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Estamos explorando el soporte de F #.

Esto muestra que lo está haciendo mal, no solo para F # sino para todos los lenguajes .Net. Empieza pensando en plantillas y archivos .xaml, que es como construir una casa y colocar alfombras y cortinas sin haber terminado la estructura.

Debería poder instalar WinUI en cualquier proyecto .Net Standard 2.0 / .Net Core 3.0 / .Net 5 como un paquete Nuget. Entonces tienes acceso a todas las clases definidas en el interior. A continuación, puede hacer referencia a dichos proyectos desde un proyecto WinUI (que podría ser solo en C #). Esto permite crear vistas de WinUI en cualquier idioma .Net. Vea cómo lo hace Xamarin.Forms .

Las clases ya están disponibles para su uso en F # (ya que son componentes de Windows Runtime, que son utilizables por todos los lenguajes .NET)

Podrás crear un diseño manualmente. Incluso podría hacerlo a través de Python usando Py / WinRT para todas las preocupaciones de WinUI.

@sylveon ¿Qué clases específicamente? Me interesaría ...

Todos ellos. La API pública de WinUI son solo componentes de Windows Runtime.

@LucasHaines La lista de los lenguajes que planeamos admitir con WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Estamos explorando el soporte de F #.

Esto muestra que lo está haciendo mal, no solo para F # sino para todos los lenguajes .Net. Empieza pensando en plantillas y archivos .xaml, que es como construir una casa y colocar alfombras y cortinas sin haber terminado la estructura.

Debería poder instalar WinUI en cualquier proyecto .Net Standard 2.0 / .Net Core 3.0 / .Net 5 como un paquete Nuget. Entonces tienes acceso a todas las clases definidas en el interior. A continuación, puede hacer referencia a dichos proyectos desde un proyecto WinUI (que podría ser solo en C #). Esto permite crear vistas de WinUI en cualquier idioma .Net. Vea cómo lo hace Xamarin.Forms .

Este tema / pregunta trata sobre herramientas. Sí, se puede hacer referencia a las bibliotecas directamente desde cualquier idioma capaz de consumirlas, pero hay una falta de definición de definiciones entre herramientas y soporte de idiomas.
Tomando Xamarin.Forms como ejemplo. Eso solo proporciona herramientas para C # y, en menor medida, F #. Es posible crear aplicaciones con VB.Net y Xamarin.Forms, pero no es _oficialmente compatible_ ya que no hay herramientas y solo documentación limitada para hacerlo.

Además, como WinUI es específico de Windows, no se puede hacer referencia a cualquier proyecto .Net Standard 2.0 / .Net Core 3.0 / .Net 5.
También existe la necesidad de soporte a nivel de proyecto / compilador / empaquetado para algunos escenarios también.

Gran equipo de trabajo en la versión v2.2 . ¿Alguna posibilidad de que podamos obtener una breve actualización sobre el estado de la v3.0?

Veo que esto se menciona varias veces, pero no hay una dirección clara en un sentido u otro. Dado que WinUI 3.0 tendrá todos los controles, ahora DEBE eliminarse el requisito de espacio de nombres para hacer referencia a los controles de la biblioteca de WinUI. Esto desordena mucho XAML, dificulta enormemente la migración y rompe la compatibilidad simple con cosas como la plataforma UNO y Avalonia.

Elimine la necesidad de xmlns:mux="using:Microsoft.UI.Xaml.Controls" de XAML. Entiendo que el código subyacente aún debe cambiar. También podría haber una configuración para esto en algún lugar del proyecto.

Elimine la necesidad de xmlns:mux="using:Microsoft.UI.Xaml.Controls" de XAML.

No será necesario en el _markup_ de XAML, pero sí sería necesario cambiar los espacios de nombres en el código subyacente.

Si desea utilizar los controles de Windows (si no se eliminan del sistema operativo), debe declarar el espacio de nombres en XAML

Si desea utilizar los controles de Windows (si no se eliminan del sistema operativo), debe declarar el espacio de nombres en XAML

Con WinUI 3.0 eso no es un escenario: no puede mezclar y combinar los controles del sistema operativo con los controles de WinUI 3.0. Eso solo funciona con WinUI 2.x en este momento porque esos controles son complementos del sistema operativo (y tenemos muchos casos incómodos en los que enviamos el tipo en ambos lugares, como NavigationView y TreeView, lo que causa ambigüedad).

Si desea utilizar los controles de Windows (si no se eliminan del sistema operativo), debe declarar el espacio de nombres en XAML

Con WinUI 3.0 eso no es un escenario: no puede mezclar y combinar los controles del sistema operativo con los controles de WinUI 3.0. Eso solo funciona con WinUI 2.x en este momento porque esos controles son complementos del sistema operativo (y tenemos muchos casos incómodos en los que enviamos el tipo en ambos lugares, como NavigationView y TreeView, lo que causa ambigüedad).

Es bueno escuchar. Hará que sea más fácil desaprobar eso del sistema operativo. Espero que la aplicación de configuración, el shell y otras partes del sistema operativo también pasen a WinUI 3.0.

¡Y esperemos que los puertos de las herramientas del administrador, Wordpad, etc., pasen a XAML reutilizando el mismo código tanto como sea posible!

@jevansaks Ok, entendido, ¡gracias por los comentarios!

@mdtauk No será necesario distinguir entre los controles heredados de 'SO' y los nuevos controles de plataforma 'WinUI 3.0' en XAML. Todo se está moviendo a WinUI 3.0 y los controles del sistema operativo no reciben más actualizaciones de funciones, como usted sabe. Después de WinUI 3.0, si un desarrollador aún desea apuntar a los controles heredados que debe desarrollar con SDK más antiguos y versiones de Visual Studio. Mantener la capacidad de hacer referencia a dos bibliotecas de control de interfaz de usuario de Microsoft / Windows desde XAML sería un obstáculo por las razones mencionadas anteriormente. Además, con el desacoplamiento de WinUI, el desarrollo finalmente puede cambiar a un camino sostenible de 'permitir' cambios como este, que ni siquiera es una ruptura.

Editar: Olvidé actualizar antes de responder, la mayor parte de esto ahora es redundante.

@robloo Me alegra que esto realmente reemplace las versiones anteriores de UWP Xaml. También espero que el sistema operativo pueda pasar a él para las aplicaciones de la bandeja de entrada y Shell.

También espero que haya muchos videos para desarrolladores que detallen el proceso de cambio a WinUI 3.0 y cómo trabajar con WinUI 3.0 con el mismo ciclo de vida que las aplicaciones Win32. No más rehidratación, mejores formas de guardar el estado y la navegación de la página, etc.

Podría ser útil (dependiendo de qué aplicaciones planean pasar a WinUI 3.0) proporcionar ejemplos de, por ejemplo, tomar Wordpad y mover el código a una nueva interfaz de usuario incorporada en WinUI, así como tomar una aplicación de bandeja de entrada como Groove Music y moverla a WinUI 3.0

Para WinUI 3, debe haber cierta coherencia en lo que respecta a la ubicación de las funciones de la aplicación en el lenguaje de diseño.

En este sentido, Configuración de la aplicación.

¿Dónde encuentro la configuración de la aplicación? ¿Hago clic en el engranaje de la esquina superior derecha? ¿Esquina izquierda inferior? ¿Hago clic en el avatar de perfil en la parte superior derecha y presiono configuración? ¿Hago clic en la parte superior izquierda? ¿Abajo a la izquierda? ¿Voy a Editar> Preferencias?

Realmente depende de si usa NavigationView ...

De: shaheedmalik [email protected]
Enviado: jueves 12 de septiembre de 2019 3:48:12 p.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: El ninja agudo [email protected] ; Comentario [email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

Para WinUI 3, debe haber cierta coherencia en lo que respecta a la ubicación de las funciones de la aplicación en el lenguaje de diseño.

En este sentido, Configuración de la aplicación.

¿Dónde encuentro la configuración de la aplicación? ¿Hago clic en el engranaje de la esquina superior derecha? ¿Esquina izquierda inferior? ¿Hago clic en el avatar de perfil en la parte superior derecha y presiono configuración? ¿Hago clic en la parte superior izquierda? ¿Abajo a la izquierda? ¿Voy a Editar> Preferencias?

-
Estás recibiendo esto porque hiciste un comentario.
Responder a este correo electrónico directamente, lo ven en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , o silenciar el hilo https: // github. com / Notifications / unsubscribe-auth / AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

¿Cómo podemos ayudarlo a ser más eficiente o exitoso con respecto a las plantillas y componentes en Visual Studio?

No deberían ser necesarios esfuerzos significativos y atributos de configuración de proyecto sin documentar para que las islas WinUI / XAML funcionen con C ++ / WinRT en Visual Studio.

No puedo enfatizar esto lo suficiente, pero lo más importante para mí es que WinUI se renderiza en más que solo Windows.

Tan pronto como vi Surface Duo, me pregunté cuál será la historia del desarrollo multiplataforma ahora que Microsoft lanzará un dispositivo con Android. Xamarin.Forms no es suficiente por varias razones obvias. Es hora de que Microsoft adopte por completo un conjunto de herramientas multiplataforma (como la plataforma UNO, pero terminado y estable) que todos sabemos que se ha solicitado en varias formas durante años. Espero que Microsoft tenga algunos planes sin mencionar para los desarrolladores aquí.

Satya declaró: "No queríamos solo crear experiencia y un dispositivo, sino que abarcara todos los dispositivos de nuestras vidas". Si desea que los desarrolladores participen en este viaje como espera Panos, esta es la mejor manera de hacerlo. De lo contrario, está pidiendo a los desarrolladores que escriban dos interfaces de usuario independientes para abarcar la 'experiencia' entre Surface Duo y el resto de la familia. No creo que sea una solicitud justa para los desarrolladores dentro de una 'familia' de dispositivos.

Se renderiza de forma diferente en cada plataforma, también conocida como "apariencia y sensación nativa".

No entiendo esto. Por favor, no lo hagas, lo último que quiero que haga Fluent Design es causar más inconsistencias, no menos.

EDITAR: comentario original eliminado

Satya declaró: "No queríamos solo crear experiencia y un dispositivo, sino que abarcara todos los dispositivos de nuestras vidas". Si desea que los desarrolladores participen en este viaje como espera Panos, esta es la mejor manera de hacerlo. De lo contrario, está pidiendo a los desarrolladores que escriban dos interfaces de usuario independientes para abarcar la 'experiencia' entre Surface Duo y el resto de la familia. No creo que sea una solicitud justa para los desarrolladores dentro de una 'familia' de dispositivos.

Ésta es EXACTAMENTE la razón por la que me desanimó que el Duo fuera Android.

Las plantillas deben ser de código abierto para eliminar cualquier área problemática que surja en ellas.

Cuándo usaré WinUI con WPF y cuándo crearé un nuevo control con un código como:
c# public class MyControl : UserControl { ... }
¿Utilizará WinUI.UserControl o WPF.UserControl?
¿Tendremos necesidad de elegir y cómo afrontarlo?

E interesante, si las herramientas XAML se van a unificar, ¿tendremos la capacidad de crear algún tipo de archivos xaml compartidos?
Algo como:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

¿Debería ser algún tipo de dialecto compartido con un espacio de nombres raíz especial? (como proyectos compartidos en Visual Studio). Podría verse como xaml condicional.

¿Utilizará WinUI.UserControl o WPF.UserControl?
¿Tendremos necesidad de elegir y cómo afrontarlo?

Esto debería suceder automáticamente en el XAML donde defina

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Eso le dice al compilador que es UWP.

public class MyControl : UserControl { ... }

Esto es realmente incorrecto. Deberías estar declarando así

public partial class MyControl { }

No se necesita herencia porque es manejada por el archivo .g.cs que especifica la herencia y también el marco que se está utilizando.

Acerca de las plantillas, estaría más feliz si hubiera más que una plantilla de Hello World. Lo que quiero decir es que Microsoft debería hacer una copia de seguridad de algunos marcos periféricos reconocidos necesarios para trabajar con aplicaciones cliente.

@weitzhandler ¡ ¡Me encantaría ver esto también !!

Los proyectos de estilo SDK para proyectos C # y Cpp / WinRT también deberían ser imprescindibles

Creo que debería haber plantillas para todos los patrones comunes de aplicaciones de Win32 e Inbox. Una lista corta que se me viene a la cabeza:

• Cinta
• Menú principal
• Interfaz de documento con pestañas
• Vista de navegación
• Barra de comandos / herramientas
• Vista de navegación superior
• Hub / Galería (sé que esto está un poco desaprobado)
• Treeview / MasterDetails (explorador de archivos, RegEdit, aplicación de administración)

Pero también debería haber plantillas de elementos para cuadros de diálogo, páginas, páginas de configuración, etc. comunes.

¿Cómo podemos ayudarlo a ser más eficiente o exitoso con respecto a las plantillas y componentes en Visual Studio?

Trabaje con la extensión C ++ para VSCode / Visual Studio. También quiero ver VS Code como un editor compatible que proporciona una experiencia similar a Visual Studio. Se supone que WinUI es OSS y también VS Code, así que creo que esto es factible.

Herramientas como Template10 y Windows Template Studio son signos de falta de funcionalidad básica. Con WinUI3 debería haber funcionalidad para lo que hacen estas herramientas. Apuesto a que muchos desarrolladores están haciendo este andamiaje básico una y otra vez ... debería ser parte del marco. No se deberían necesitar herramientas adicionales. Tal vez incluso debería tener que apagar el andamio MVVM para esos raros casos en los que le gustaría estar sin él.

Después de trabajar un poco con ASPNET Core, me falta la inyección de dependencia. Esta característica está disponible de forma nativa en ASPNET Core. Simplemente funciona, sin que usted haga nada adicional. Y puede agregar o modificar servicios tan fácilmente si lo desea. Pero para UWP de hoy, debe crearlo usted mismo o usar algo como WTS para comenzar, pero aún se siente como si estuviera pegado después. WinUI3 con la inyección de dependencia nativa adecuada sería muy útil.

No creo que la presencia de sistemas de plantillas muestre una falta de funcionalidad básica, creo que resalta la calidad de las comunidades de apoyo que armarían estos sistemas de plantillas.

Herramientas como Template10 y Windows Template Studio son signos de falta de funcionalidad básica.

Veo cosas como esta como una extensión de la funcionalidad básica. Por supuesto, cosas como esta podrían llevarse a cabo internamente, pero luego es más para que el equipo central las mantenga y respalde. A medida que el equipo central hace más, tiende a significar que están más dispersos y, por lo tanto, todo lleva más tiempo. Si Msft cree que tienen presupuesto para llevar cosas como esta al equipo principal, me encantaría tener una charla con alguien al respecto;)

Solo algunas ideas sobre el estilo simplificado y las plantillas de control, como facilitar la adición de un comportamiento personalizado para los estilos y controles integrados. El ejemplo perfecto aquí es el estilo Button , cuando necesitamos anular toda la plantilla de control para cambiar el color de desplazamiento o usar el radio del borde. Establecer algunos de ellos directamente, como en css , evitará la creación de kilómetros de código XAML

@AntiPasha ¿Has oído hablar del estilo de

Cambiar el color de desplazamiento de un botón sería simplemente:

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

También se agregó una propiedad Control.CornerRadius en el 17763 SDK y el equipo de WinUI también está introduciendo recursos reemplazables para agregar fácilmente personalización de aplicaciones o páginas sin tener que cambiar el estilo de los controles: https://github.com/microsoft/microsoft-ui- xaml-specs / blob / user / chigy / roundcorner / active / RoundedCorner / roundcorner.md # personalización -opciones

E interesante, si las herramientas XAML se van a unificar, ¿tendremos la capacidad de crear algún tipo de archivos xaml compartidos?
Algo como:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

¿Debería ser algún tipo de dialecto compartido con un espacio de nombres raíz especial? (como proyectos compartidos en Visual Studio). Podría verse como xaml condicional.

@Tirraon, este es un ejemplo realmente interesante, pero creo que cuando hablamos de unificar herramientas, es mejor comenzar con la mentalidad de que las plataformas van a existir como lo hacen hoy, y no estamos tratando de crear otro estándar Xaml. equivalente.

Podemos usar el espacio de nombres predeterminado para diferenciar a qué plataforma de "nivel superior" pertenece el archivo xaml, por ejemplo, podríamos tener los siguientes espacios de nombres predeterminados para cada plataforma XAML (estos son en su mayoría hipotéticos, así que tómelos con un grano de sal 😄):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
avalonia: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

Entonces, para mezclar WinUI con WPF usando Xaml Islands, tiene un marcado que se ve así:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

¿Qué piensas?

@stevenbrix
En su ejemplo para UWP, renderizará ambos botones, ¿no es así?
Quiero decir, por ejemplo, cuando xmlns = "... / xaml / presentation" es un espacio de nombres de nivel superior y UserControl wutg StackPanel están disponibles tanto en uwp como en wpf, ¿entonces el segundo botón no estaría disponible también en ambas plataformas?

cuando hablamos de unificar herramientas, es mejor comenzar con la mentalidad de que las plataformas van a existir como lo hacen hoy

Sí, estoy totalmente de acuerdo con eso.

En su ejemplo para UWP, renderizará ambos botones, ¿no es así?
Quiero decir, por ejemplo, cuando xmlns = "... / xaml / presentation" es un espacio de nombres de nivel superior y UserControl wutg StackPanel están disponibles tanto en uwp como en wpf, ¿entonces el segundo botón no estaría disponible también en ambas plataformas?

@Tirraon , el ejemplo que di es puramente para la aplicación WPF que usa Xaml Islands para modernizar gradualmente su aplicación. No está diseñado para un marcado "estándar" que se utiliza entre las aplicaciones WPF y WinUI, ¿tiene sentido?

Actualmente, los autores de aplicaciones que desean utilizar Xaml Islands tienen que crear controles de usuario para cada isla. Luego hacen referencia al tipo a través de una cadena en su marcado WPF, en lugar de incrustar naturalmente elementos WinUI en el marcado WPF.

Estoy en mi teléfono ahora mismo, pero puedo obtener un antes y un después más concreto de lo que propongo una vez que esté cerca de mi PC.

@stevenbrix
Oh, ahora te tengo, gracias.

@stevenbrix
Oh, ahora te tengo, gracias.

@Tirraon genial! Me alegro de que estemos en la misma página ☺️

Perdón si mi idea parecía surgir del campo izquierdo, hemos estado en las primeras discusiones sobre cómo podríamos unificar potencialmente las herramientas, con el objetivo de mejorar el escenario de la isla Xaml. ¿Crees que hay valor en algo así?

FWIW, definitivamente creo que hay mérito en algo como lo que estabas proponiendo. Pero estoy tratando de concentrarme en algo que podamos hacer en el marco de tiempo de WinUI3 / .NET5.

Descubra cómo representar WinUI Xaml en alguna canalización que traduzca la salida a un lienzo nativo y reciba información de un sistema de mensajes nativo. Como WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

No es necesario implementar todos los adaptadores en el lanzamiento, solo los que se requieren para admitir Windows 10.

De: Steven Kirbach [email protected]
Enviado: jueves 7 de noviembre de 2019 9:13:46 a.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: El ninja agudo [email protected] ; Comentario [email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

@stevenbrix https://github.com/stevenbrix
Oh, ahora te tengo, gracias.

@Tirraon https://github.com/Tirraon ¡genial! Me alegro de que estemos en la misma página ☺️

Perdón si mi idea parecía surgir del campo izquierdo, hemos estado en las primeras discusiones sobre cómo podríamos unificar potencialmente las herramientas, con el objetivo de mejorar el escenario de la isla Xaml. ¿Crees que hay valor en algo así?

FWIW, definitivamente creo que hay mérito en algo como lo que estabas proponiendo. Pero estoy tratando de concentrarme en algo que podamos hacer en el marco de tiempo de WinUI3 / .NET5.

-
Estás recibiendo esto porque hiciste un comentario.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 , o darse de baja https://github.com/ notificaciones / unsubscribe-auth / AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Sí, por favor, el escenario de la isla XAML es horrible en este momento

@sharpninja
Deberías echar un vistazo a Uno
https://platform.uno/
También será compatible con WinUI 3.0 para todas las plataformas.
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
No tengo mucha experiencia con las islas Xaml y trabajo normalmente con UWP simple. Pero definitivamente necesito mirarlo más de cerca.
Mi propuesta no estaba relacionada con Xaml Islands en sí, sino más relacionada con WinUI en general, ya que funcionará en más de una plataforma.

Mi propuesta no estaba relacionada con Xaml Islands en sí, sino más relacionada con WinUI en general, ya que funcionará en más de una plataforma.

@Tirraon ,

He hablado brevemente con @jeromelaban y compañía sobre exactamente lo que está proponiendo, y definitivamente hay interés. Todavía no hay un plan o compromisos concretos, ya que todavía estamos en las primeras etapas de las discusiones. Este tipo de información es excelente y nos ayuda a comprender mejor el valor que aporta a nuestros clientes 😄

Por el escenario de la isla XAML me refiero al de C ++. Consulte mis mensajes anteriores en este hilo para ver la lista de problemas que he enfrentado.

Sí, por favor, el escenario de la isla XAML es horrible en este momento

Por el escenario de la isla XAML me refiero al de C ++. Consulte mis mensajes anteriores en este hilo para ver la lista de problemas que he enfrentado.

@sylveon Veo tus comentarios (enlaces a continuación), y sí, eso suena bastante terrible. Lamento que estés experimentando eso, estoy seguro de que lo mejoraremos.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Gran parte del dolor por el que estás pasando suena relacionado con el sistema del proyecto, y sé que es algo que está en los radares de muchas personas (aunque soy bastante distante). ¿Has visto este video que algunos de los miembros de nuestro equipo hicieron sobre las herramientas XAML? Ese enlace debería iniciar el video de YouTube en el punto donde @ michael-hawker y @ marb2000 comienzan a entrar en la nueva experiencia de Xaml Island. Definitivamente nos preocupamos por C ++, pero no sé si solo hemos abordado la experiencia de .NET hasta ahora, o si también ha habido mejoras en C ++. Probablemente podrían comentar más sobre eso.

Hay muchas cosas que harán que la experiencia de Xaml Island sea fácil y natural de usar. El aspecto al que me refiero es que actualmente, la forma en que incluye un contenido de Island of UWP en WPF es así (del video de arriba):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

Creo que podemos hacerlo mejor que eso y proporcionar algo como esto:

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

He hablado brevemente con @jeromelaban y compañía sobre exactamente lo que está proponiendo, y definitivamente hay interés. Todavía no hay un plan o compromisos concretos, ya que todavía estamos en las primeras etapas de las discusiones. Este tipo de información es excelente y nos ayuda a comprender mejor el valor que aporta a nuestros clientes.

¡Hay tanto, tanto interés! (Esta conversación aparece en todas partes) Si WinUI post 3.0 cambiara a implementaciones multiplataforma, tendría mucho soporte para los desarrolladores. Solo mire la discusión sobre el n. ° 1461. A corto plazo, usar la tecnología de Uno Platform para convertir XAML / C # en HTML / WASM para que las aplicaciones UWP se ejecuten en todas las plataformas sería increíble. A largo plazo, me preocupa el impacto en el rendimiento de ejecutar en Electron o un navegador y hay espacio para una arquitectura más eficiente.

En pocas palabras, sé que todos están ocupados con WinUI 3.0 en este momento. Pero cuando eso termine , sería genial si conectamos a @ marb2000 , @jevansaks y otros para descubrir la mejor manera de hacer que UWP se renderice en todas partes. Esa también sería una discusión comunitaria muy interesante para una futura convocatoria.

WinUi es el único camino sano que lleva a Neo y Duo a sobrevivir

De: robloo [email protected]
Enviado: jueves 7 de noviembre de 2019 12:00:07 p.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: El ninja agudo [email protected] ; Mencione menció[email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

@stevenbrix https://github.com/stevenbrix

He hablado brevemente con @jeromelaban https://github.com/jeromelaban y compañía sobre exactamente lo que está proponiendo, y definitivamente hay interés. Todavía no hay un plan o compromisos concretos, ya que todavía estamos en las primeras etapas de las discusiones. Este tipo de información es excelente y nos ayuda a comprender mejor el valor que aporta a nuestros clientes.

¡Hay tanto, tanto interés! (Esta conversación aparece en todas partes) Si WinUI post 3.0 cambiara a implementaciones multiplataforma, tendría mucho soporte para los desarrolladores. Solo mire la discusión en # 1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . A corto plazo, usar la tecnología de Uno Platform para convertir XAML / C # en HTML / WASM para que las aplicaciones UWP se ejecuten en todas las plataformas sería increíble. A largo plazo, me preocupa el impacto en el rendimiento de ejecutar en Electron o un navegador y hay espacio para una arquitectura más eficiente.

En pocas palabras, sé que todos están ocupados con WinUI 3.0 en este momento. Pero cuando eso termine, sería genial si conectamos a @jeromelaban https://github.com/jeromelaban , @ marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks y otros para descubra la mejor manera de hacer que UWP se renderice en todas partes. Esa también sería una discusión comunitaria muy interesante para una futura convocatoria.

-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 , o darse de baja https://github.com/ notificaciones / unsubscribe-auth / AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi es el único camino sano que lleva a Neo y Duo a sobrevivir

Tiendo a estar de acuerdo, pero obtengo la misma interfaz de usuario de una aplicación de Windows, que se ejecuta en Android y Surface Duo. Con una mínima intervención del desarrollador, ese es el santo grial.

Si WinUI tiene alguna posibilidad de ser una plataforma de desarrollo principal y darle a Windows la oportunidad de no convertirse en un receptáculo de las aplicaciones de otras plataformas a largo plazo. (No siempre es algo malo, cuando se trata de grandes aplicaciones establecidas, pero para LoB y las próximas grandes aplicaciones ...)

Estoy creando mi propio lenguaje orientado a aplicaciones y quiero admitir el uso de WinUI con XAML y mi lenguaje para código subyacente. Sería bueno si las herramientas ofrecieran la capacidad de que un lenguaje proporcione generación de código para XAML. Lo que sería aún mejor es si el generador de código XAML compilara IL como una clase parcial que podría completarse con cualquier lenguaje. Eso significaría que el generador de código generaría un ensamblado de IL compilable.

Estoy creando mi propio lenguaje orientado a aplicaciones y quiero admitir el uso de WinUI con XAML y mi lenguaje para código subyacente. Sería bueno si las herramientas ofrecieran la capacidad de que un lenguaje proporcione generación de código para XAML. Lo que sería aún mejor es si el generador de código XAML compilara IL como una clase parcial que podría completarse con cualquier lenguaje. Eso significaría que el generador de código generaría un ensamblado de IL compilable.

Existe XAML Direct, pero es compatible con C # y C ++ en este momento.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Eso no es lo que quiero decir. Me refiero a que la salida de la herramienta de generación de código sea IL, no C # o C ++. De esa manera, mi compilador puede transformar el XAML en IL y luego heredar esa clase.

@sharpninja También sería beneficioso, si también puede generar código de

De esa manera, podemos combinarlo con MIDL y XLang para generar una biblioteca COM y archivos WinMD para usar en todos los escenarios compatibles con XLang.

Con mi sombrero de C ++, lo que me gustaría ver con respecto a las herramientas de WinUI para C ++, sería que Microsoft finalmente se pusiera al día con lo que C ++ Builder ha estado haciendo desde mediados de los 90.

Proporcione herramientas RAD reales para el desarrollo basado en C ++.

C ++ / CLI no lo logró, aunque con los formularios hubo algunas soluciones.

C ++ / CX parecía que lo sería, pero requirió un poco más de esfuerzo de lo que C ++ Builder es capaz de hacer.

Ahora, C ++ / WinRT podría ser C ++ 17 estándar, pero la experiencia general para los desarrolladores de escritorio se siente como una degradación, con el aumento en el texto estándar que uno tiene que escribir manualmente, cuidado adicional de cómo los tipos COM superan el límite ABI y la falta de diseñador. apoyo.

Por lo tanto, todavía estoy usando C ++ / CX por el momento, ya que no siento que tenga que lidiar con todo el texto estándar requerido por el compilador MIDL y el soporte COM ABI.

Por otro lado, con mi sombrero .NET puesto, me gustaría ver que las bibliotecas solo de C ++ como DirectX finalmente se expongan como componentes de WinUI, algo de amor por Blend y recordando que F # supuestamente también es un lenguaje .NET de Microsoft.

He tenido una cantidad considerable de dificultades al intentar cambiarme a WinUI. Hay varias bibliotecas de primera y tercera parte que no utilizan WinUI en este momento y las dependencias de ellas se vuelven problemáticas. Por ejemplo, el SDK de comportamientos.

Esta es una idea que tuve mientras hablaba sobre StatusBar en UWP Community Discord.

En Visual Studio, haga que la caja de herramientas incluya entradas para los controles WPF que faltan en UWP y, cuando se seleccionen esas entradas, muestre una ventana emergente que explique cómo simular el control tradicional.

Esta idea proviene del deseo de facilitar la transición para las personas que vienen de WPF (u otros marcos) donde esperan ver ciertos controles, y no encontrar esos controles puede resultar una experiencia discordante. ¿Cómo se sabe que CommandBar se puede utilizar como StatusBar? Creo que tenemos que hacer que sea lo más simple posible para que las personas pasen a WinUI. Esto podría servir para llenar algunos vacíos sin tener que desarrollar realmente todos los controles faltantes.

EDITAR:
Y para completar, aquí hay algo más que dije sobre la barra de estado ... solo muestra cómo alguien podría acercarse a UWP (o WinUI) si no está familiarizado con él ...

Re: StatusBar: estaba pensando desde la perspectiva de los usuarios de marcos tradicionales que prueban UWP, y veo que no tiene StatusBar, que sigue siendo un elemento básico en muchas aplicaciones. Sí, CommandBar podría ser incluso mejor. Pero la gente no sabe qué es CommandBar o puede adivinar que es otra cosa. Alguien de arriba incluso sugirió que agregara una cuadrícula, la pusiera en la parte inferior, la hiciera una fila de alto y agregara varios controles para mostrar cosas. Por lo tanto, parece que incluso los diseñadores de Xaml existentes no conocen CommandBar. De todos modos, tal vez tenga razón, tal vez CommandBar sea mejor, pero Paul Thurrot no lo usó en su aplicación de bloc de notas para UWP, usó una cuadrícula. Entonces parece que CommandBar no se está comunicando como reemplazo de StatusBar. Los desarrolladores casuales (o nuevos) todavía buscan StatusBar y no lo encuentran. Sé que Paul Thurrot no es un desarrollador, pero entiendes mi punto.

Sería genial si los fragmentos también se inyectaran en el xaml con un caso de uso normal.

De: Gavin-Williams [email protected]
Enviado: martes 18 de febrero de 2020 7:05:39 p.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: El ninja agudo [email protected] ; Mencione menció[email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

Esta es una idea que tuve mientras hablaba sobre StatusBar en UWP Community Discord.

En Visual Studio, haga que la caja de herramientas incluya entradas para los controles WPF que faltan en UWP y, cuando se seleccionen esas entradas, muestre una ventana emergente que explique cómo simular el control tradicional.

Esta idea proviene del deseo de facilitar la transición para las personas que vienen de WPF (u otros marcos) donde esperan ver ciertos controles, y no encontrar esos controles puede resultar una experiencia discordante. ¿Cómo se sabe que CommandBar se puede utilizar como StatusBar? Creo que tenemos que hacer que sea lo más simple posible para que las personas pasen a WinUI. Esto podría servir para llenar algunos vacíos sin tener que desarrollar realmente todos los controles faltantes.

-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 , o darse de baja https://github.com/ notificaciones / unsubscribe-auth / AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

La historia del desarrollador debe incluir una especie de lista de comparación.

Conceptos que son intrínsecos a las aplicaciones Win32, por ejemplo, barras de estado, barras de herramientas, menús, pinzas, pestañas, etc. en una lista y los equivalentes de WinUI en la otra.

La página en sí incluye ejemplos de código de ambos, para mostrar cómo la interfaz de usuario de una aplicación existente se puede mover a WinUI.

Preguntas abiertas)
¿Sería beneficioso si proporcionáramos una herramienta de migración que automatizara los pasos 1-3?

Si. Admito 1 aplicación de Windows Forms "heredada" (heredada significa que no hay presupuesto para reescribir) y 2 o 3 aplicaciones WPF heredadas. La aplicación WinForms puede quedar varada, ¡pero una herramienta para ayudar a portar las aplicaciones WPF rápidamente a WinUI 3 sería genial!

MSIX es el método de empaquetado moderno para todas las aplicaciones. Para WinUI en Win32, ¿deberíamos admitir ClickOnce? ¿Para qué otros métodos de embalaje deberíamos incluir soporte? Especialmente para WinUI en Win32

Actualmente usamos ClickOnce para publicar aplicaciones en los escritorios de nuestros usuarios. Aún sería deseable algún modelo de actualizaciones automáticas.

@JeffSchwandt

Esos pasos estaban relacionados con la conversión de proyectos de WinUI que usaban versiones anteriores (1-2) a la versión 3.

Convertir una aplicación WPF en una WinUI no es particularmente factible de forma automatizada (sin una enorme cantidad de esfuerzo, pero incluso entonces sería extremadamente propenso a errores).

Espero que este sea el hilo adecuado para publicar esta solicitud.

Rust necesita desesperadamente un marco de interfaz de usuario adecuado en este momento. Sería bueno si WinUI pudiera admitir Rust en el futuro con un SDK nativo y algunas herramientas.

Espero que este sea el hilo adecuado para publicar esta solicitud.

Rust necesita desesperadamente un marco de interfaz de usuario adecuado en este momento. Sería bueno si WinUI pudiera admitir Rust en el futuro con un SDK nativo y algunas herramientas.

Buenas noticias, Rust / WinRT está en desarrollo, lo que permitirá que las aplicaciones rust utilicen API de WinRT como WinUI. Eche un vistazo a https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks ¡Oye, gracias por la respuesta! Sí, sé que Kenny funciona en Rust / WinRT, pero me pregunto si WinRT es la única capa de API compatible con WinUI. No estoy seguro de cómo encajaría esto con el hecho de que el uso de la API de WinRT desde las aplicaciones de escritorio estuvo disponible solo en Windows 10 1903, mientras que WinUI tiene como objetivo admitir versiones anteriores de Windows 10.

Rust / WinRT (como C ++ / WinRT) debería funcionar hasta Windows 7. WinRT siempre ha funcionado en aplicaciones de escritorio / win32. Solo ciertas API tenían requisitos de almacenamiento / uwp / empaquetado (no WinRT en su conjunto). Siempre que WinUI no tenga esos requisitos, podrá usar WinUI desde aplicaciones de escritorio a través de C ++ / WinRT y Rust / WinRT en cualquier plataforma compatible.

Las aplicaciones de escritorio WinUI deberían admitir Live Tiles y Tile Updating, con buenas muestras simples y herramientas SDK para crear Tiles más fácilmente que las aplicaciones UWP de hoy.

No estoy seguro de cómo encajaría esto con el hecho de que el uso de la API de WinRT desde aplicaciones de escritorio estuvo disponible solo en Windows 10 1903

WinUI Desktop está siendo diseñado para WinUI 3.0 en este momento, y eso debería permitir que las aplicaciones simples de Win32 usen el nivel inferior de WinUI (el plan actual es 1803).

La interfaz de usuario de Windows debe admitir al menos los principales marcos MVVM: MVVM Light, Prism y Caliburn. Desafortunadamente, su problema documentado con los cambios en INotifyPropertyChanged e INotifyCollectionChanged rompió ObservableCollectionciertamente rompe MVVM Light, y probablemente también los otros dos marcos. Pensé que deberías saberlo.

Desafortunadamente, su problema documentado con los cambios en INotifyPropertyChanged e INotifyCollectionChanged que rompen ObservableCollection ciertamente rompe MVVM Light, y probablemente también los otros dos marcos. Pensé que deberías saberlo.

¡Gracias @terrycox! Somos conscientes y esto será abordado por WinUI 3.0 RTM, e idealmente en una versión preliminar antes de esa fecha;)

@terrycox La interfaz de usuario de Windows debe admitir al menos los principales marcos MVVM: MVVM Light, Prism y Caliburn. ... tu problema documentado

Sí, debería solucionar problemas documentados, pero no hay necesidad de una biblioteca de interfaz de usuario .Net, incluida WinUI, para admitir un marco MVVM. Solo necesita admitir objetos que representen elementos de la interfaz de usuario. Un .Net MVVM o marco reactivo es una forma de generar y alterar objetos .Net que representan la IU basada en objetos que representan datos. Ninguno necesita saber sobre el otro. Cualquier marco se puede combinar con cualquier biblioteca de interfaz de usuario.

pero no hay necesidad de una biblioteca de interfaz de usuario .Net, incluida WinUI, para admitir un marco MVVM.

Pero cosas como eventos e interfaces que UIElements conoce son necesarias y eso es lo que se rompió.

De: Charles Roddie [email protected]
Enviado: miércoles, 25 de marzo de 2020 2:28:46 p.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: El ninja agudo [email protected] ; Mencione menció[email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

@terrycox https://github.com/terrycox La interfaz de usuario de Windows debería admitir al menos los principales marcos MVVM: MVVM Light, Prism y Caliburn. ... tu problema documentado

Sí, debería solucionar problemas documentados, pero no hay necesidad de una biblioteca de interfaz de usuario .Net, incluida WinUI, para admitir un marco MVVM. Solo necesita admitir objetos que representen elementos de la interfaz de usuario. Un .Net MVVM o marco reactivo es una forma de generar y alterar objetos .Net que representan la IU basada en objetos que representan datos. Ninguno necesita saber sobre el otro. Cualquier marco se puede combinar con cualquier biblioteca de interfaz de usuario.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 , o cancele la suscripción https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

Las herramientas de dotnet cli deben usarse junto con un. Net core sdk.
Los comandos como dotnet new y dotnet build deberían ser suficientes, sin una dependencia estricta de la instalación de Visual Studio. ¡Únase por completo a .Net Core Era!

• Será bueno si el diseñador xaml es rápido. El diseñador XAML actual es lento y siempre arroja algún error que dice que se produjo una excepción y que no funcionará. Corríjalo y proporcione un diseñador sólido.

• Actualmente, uwp no tiene ninguna API que pueda detectar la pantalla de bloqueo. Sería bueno si contamos con API que puedan detectar la pantalla de bloqueo y dar booleanos como valores de retorno. También deberíamos poder mostrar algunas animaciones e insignias después de bloquear o desbloquear.
  - API de pantalla de bloqueo existente

• Mi problema explicado

En la línea del comentario de

Me gustaría ver una plantilla de aplicación que crea una aplicación .NET 5 con la interfaz de usuario de WinUI 3.0 que hace referencia a una aplicación de host de la tienda .NET 5. Esto permitiría menos instalaciones redundantes de .NET 5.0

En una aplicación de escritorio WinUI, ¿cómo se pasa de muxc.Window.ThisPtr a un hWnd a la ventana nativa de Win32?

Acabo de probar las nuevas plantillas de mayo de 2020 para WinUI 3 Preview 1 para escritorio porque me gusta esta idea.

Pero tengo una pregunta. Con WinUI como la plataforma de interfaz de usuario nativa en Windows, me sorprende la falta de comunicación para que también sea parte de Windows 10.

Mi aplicación Hello World resultante tenía alrededor de 120 MB de tamaño. Claro, el espacio es barato, pero no tenía dependencias por mi cuenta aquí. De esto, WinUI consumió una cantidad considerable de espacio, casi tanto como el propio .NET 5 incluido. Eso es solo para la compilación x64. Incluya x86 en un paquete multiplataforma y duplique ese tamaño. Agregue algunas otras dependencias y podríamos estar buscando fácilmente una aplicación de 300 MB para empaquetar y distribuir.

¿Por qué WinUI 3 no es simplemente parte de la edición de Windows de .NET 5? ¿Es parte del esfuerzo de modularización de .NET Core? Pero si no, ¿dónde está el lugar para ello? ¿Verdaderamente insidiosa la carpeta de cada aplicación? ¿Como interfaz de usuario oficial de Windows 10 ...?

¿O será parte de Windows 10 en el futuro? Si WinUI se tratara más como una biblioteca de sistemas y .NET 5 comenzara a distribuirse con Windows más adelante, estaríamos buscando aplicaciones comparativamente pequeñas en su lugar. Pero, con suerte, esta es exactamente la historia para Windows 10X al menos, y tal vez también Windows 10 non-X más adelante. Excluyendo estas dos bibliotecas, así como la DLL puente de Windows 10 SDK C # / WinRT, el tamaño de la aplicación se desploma a 1-5 MB.

@ryandemopoulos ha dicho en Discord que WinUI se entregará como un paquete de marco, por lo que las aplicaciones que usan Store o MSIX para la distribución no tendrán que llevar su propia versión de WinUI, ya que todas compartirán la misma copia.

Hacer que WinUI forme parte de Windows mismo anularía el punto de que WinUI se desacople del sistema operativo.

"Disponibles de forma fiable y no en el tamaño de la aplicación" es la preocupación. Espero que .NET 5 se distribuya de manera similar.

@lmcdougald Lo invito a abrir un problema en .NET Core Installer y solicitar que .NET 5 use Framework Packaging también para el mantenimiento.

@jonasnordlund hay otra discusión # 2500 donde estamos hablando de la implementación de WinRT Runtime. Quizás encuentres alguna respuesta ahí. :)

@ marb2000 Abrí un problema, pero honestamente estoy desconcertado. ¿No se considera esto esencial para cualquier aplicación que ofrezca Windows 10X?

Aquí hay una compilación de varias características, algunas de las cuales no son directamente WinUI, pero su falta afecta directamente la experiencia de cualquier desarrollo de cliente .NET, incluidos los clientes UWP, y especialmente los clientes de aplicaciones LoB.

• La primera y más importante prioridad para mí es que nutras la Plataforma Uno. Para mí, es lo que hace que UWP sea relevante, me habría comprometido con XF u otra tecnología si Uno no estuviera presente. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• API abstracta de administración de identidad del lado del cliente que se utilizará desde ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Soporte completo de anotaciones de datos, validaciones y títulos de IU, longitudes de cadenas, atributos obligatorios, campos de solo lectura, marcas de agua, etc., etc., etc. (https://bit.ly/3gcMJ3a)
• Mejore OData para que se convierta en una alternativa adecuada a lo que solían ser los servicios de RIA. Por ejemplo: generación de atributos de soporte, implementaciones de interfaz, tipos genéricos, documentos XML (https://github.com/OData/odata.net/issues/1746)
• Incorpora todas las funciones que faltan de WPF
• x:Bind también debe tener todas las características que tiene Binding , como ámbitos o enlaces anidados (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Reinicio en caliente (https://github.com/microsoft/ProjectReunion/issues/44)
• Más que simples plantillas de Hello World. Como los que se adaptan al inicio de sesión de usuario, MVVM, enrutamiento, proyectos x-plat (como Uno-Platform), etc. En otras palabras, dé más poder a WTS.
• Características de diseño del editor XAML WYSIWYG como en WinForms, como acoplamiento, espaciado, etc., ¡esto parece haberse completado! ❤

Gracias por tu compilación @weitzhandler , muy conveniente.

El equipo de WinUI tiene una excelente relación con el equipo de producto de Uno (que no es de Microsoft), el equipo de Xamarin Forms / MAUI y React Native. Colaboramos activamente con ellos y les deseamos un futuro exitoso.

Acerca de las funciones de WPF que faltan, ¿puede enumerar las principales, por favor? Cerrar la brecha entre WPF y WinUI es uno de nuestros objetivos. Sin embargo, se necesitarán varios lanzamientos.

A propósito de plantillas más complejas. Window Template Studio tiene esta misión.

Hice un problema para intentar recopilar áreas donde falta WinUI en comparación con WPF # 719 @weitzhandler @ marb2000

A propósito de plantillas más complejas. Window Template Studio tiene esta misión.

@ marb2000 ¿ Podríamos incorporar Window Template Studio a nuestro VSIX? ¿O quizás viceversa? ¿Simplemente use Window Template Studio como el vehículo para enviar todas las plantillas de WinUI3 (y Project Reunion) en el futuro?

A propósito de plantillas más complejas. Window Template Studio tiene esta misión.

@ marb2000 ¿ Podríamos incorporar Window Template Studio a nuestro VSIX? ¿O quizás viceversa? ¿Simplemente use Window Template Studio como el vehículo para enviar todas las plantillas de WinUI3 (y Project Reunion) en el futuro?

👀 @crutkas @sibille

Sugiero pasar un tiempo con C ++ Builder (VCL / FMX) y Qt Creator / Design Studio, para aprender qué es posible con C ++ y las herramientas modernas.

Idealmente, WinUI ofrecería herramientas similares a las de estos productos para las GUI multiplataforma escritas en C ++.

Lo que me importa es la experiencia de desarrollo de .NET y tener una experiencia similar para los casos de uso me veo obligado a usar C ++, que por alguna razón no está disponible para nosotros.

C ++ Builder y QtCreator logran tal experiencia, y sería bienvenido si los desarrolladores de .NET pudieran sentirse como en casa cuando tengan que pasar un par de días escribiendo código C ++ / WinRT.

¿Por qué hacer esto sobre los desarrolladores de .NET? La experiencia C ++ XAML es simplemente mala, no importa si eres un desarrollador de C ++ o .NET.

Creo que será genial si abren el camino para habilitar la misma ejecución de XAML en escritorio, web (Edge), móvil e IoT.

¿Cuándo podremos usar WinUI 3 en un proyecto de C ++ sin C #, Xaml o diseñador?
¿También hay alguna noticia sobre la fecha del código abierto del núcleo c ++ de WinUI 3?

Editar: Supongo que obtuve una respuesta para mi primera pregunta, parece que hay una plantilla de proyecto C ++ WinUI 3 en WinUI 3.0 Preview 1 :

Después de instalar la extensión .vsix, puede crear un nuevo proyecto WinUI 3.0 buscando "WinUI" y seleccionando una de las plantillas C # o C ++ disponibles.

El caso de uso que me encantaría que mejorara WinUI es el de crear pequeñas herramientas basadas en GUI para el personal de soporte de TI de primera línea que a menudo están escritas en PowerShell. Sería genial poder crear este tipo de herramientas en Visual Studio Code. Incluso una opción de desarrollo de VSCode basada en C # sería un gran paso. Visual Studio completo se siente bastante pesado y complejo para este caso.

Actualmente, los entornos empresariales están utilizando herramientas como estas en su lugar:

• https://poshgui.com/ (asistente XAML basado en web)
• Sapien PowerShell Studio 2020 (propietario)
• Admin Script Editor (ASE) (un proyecto ahora abandonado)

Aquí se describen otros patrones de uso común "use Visual Studio para XAML":

• Cree una interfaz gráfica simple para un script de PowerShell
• Cómo construir una GUI de PowerShell para sus scripts

Mi pregunta está en el contexto de la pregunta de @mqudsi que hizo en mayo, pero nadie respondió.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

Dado que esta es una aplicación de escritorio, no podemos usar ICoreWindowInterop y he probado swags aleatorios como new HandleRef(this, ThisPtr) donde 'this' es del tipo Microsoft.UI.Xaml.Window pero sigo viendo el error para el identificador de ventana no válido. Una vez que finalmente obtengo ese hwnd, puedo intentar usar más COM para cambiar el estilo de la ventana y compartir con otros para que no sientan el dolor que yo siento ahora :).

Para cualquier persona interesada, este es el enfoque rápido que utilicé para tomar el hWnd de la ventana principal para poder dejarla sin bordes. La solución completa para WPF equivalente a WindowStyle = None está aquí .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

En este momento, no parece haber una forma fácil de encontrar / documentada para obtener el hWnd cuando su WinUI está en un proceso de escritorio, por eso recurrí al enfoque que utilicé. Parece funcionar bastante bien.

Creo que tal vez UWP y Universal Windows como términos deberían desaparecer. Los términos conllevan un bagaje desafortunado que lleva a los desarrolladores a rehuir.

¿Quizás podríamos reemplazar la plantilla WinUI (Universal Windows) con WinUI (Win64)? ¿Entonces tienes la opción de Escritorio o Tienda?

Win64 es confuso: implicaría que la API de Win32 solo admite 32 bits y que, a la inversa, UWP solo admite 64 bits, los cuales son falsos.

El nombre de Win32 por sí solo ya confunde a muchos principiantes, no necesitamos Win64 para empeorar las cosas.

@VagueGit algo que he aprendido es que elegir el nombre correcto y elaborar la historia es una de las cosas más complicadas. Mejor que reemplazar un nombre, nosotros (Microsoft) deberíamos entregar el producto (y la historia) correctos para ayudarlo a tener éxito. UWP es una terminología muy conocida como Win32, por lo que deberíamos seguir utilizándola.

Este es nuestro enfoque (muy simplificado):

WinUI se puede utilizar en dos "tipos" de aplicaciones que se dirigen a diferentes dispositivos:

• Su aplicación se dirige a una gran cantidad de dispositivos con muchas entradas y factores de forma. Luego usa UWP. UWP fue creado para eso; por lo tanto, debe cumplir con requisitos como modelo de empaque, tienda, modelo de aplicación, contenedor de seguridad, etc.
• Su aplicación solo tiene como destino el escritorio y requiere acceso completo al sistema operativo. Use Win32 o Desktop (que es como Visual Studio llama a WPF, WinForms, MFC, aplicaciones).

WinUI en las aplicaciones para UWP y WinUI en las aplicaciones de escritorio (o la

@ marb2000 Nombrar las cosas es difícil, estuvo de acuerdo. Pero, lamentablemente, algunos nombres son tóxicos y deberían dejarse atrás. Por eso, de vez en cuando, los productos se renombran. UWP es uno, pero ese es solo mi punto de vista ... y todos con los que hablo. Pero ahí lo tienes.

Tenemos una aplicación para UWP que queremos migrar a WinUI. No usamos la API de Win32, solo apuntamos al escritorio y no queremos usar la tienda. ¿Cómo encaja eso?

@ marb2000 Nombrar las cosas es difícil, estuvo de acuerdo. Pero, lamentablemente, algunos nombres son tóxicos y deberían dejarse atrás. Por eso, de vez en cuando, los productos se renombran. UWP es uno, pero ese es solo mi punto de vista ... y todos con los que hablo. Pero ahí lo tienes.

Tenemos una aplicación para UWP que queremos migrar a WinUI. No usamos la API de Win32, solo apuntamos al escritorio y no queremos usar la tienda. ¿Cómo encaja eso?

¿Para quién es la aplicación exactamente?

Como consumidor que hace todo lo posible por usar aplicaciones para UWP, si la aplicación no está en la tienda, probablemente no la tocaré, y mucho menos la veré.

No te preocupes @shaheedmalik , no te

Por lo tanto, sabemos que existe un mercado para las aplicaciones empresariales Win64 y creemos que estamos entre los pocos desarrolladores empresariales que han entregado aplicaciones Win64 por las que pagarán los clientes empresariales. Sé que hay algunos desarrolladores en este hilo que siguen la ruta Universal Windows / multiplataforma, pero son bastante raros. La mayoría de los desarrolladores de negocios en mi experiencia apuntan a un factor de forma específico.

Entonces, hablando desde la perspectiva de una empresa de desarrollo que ha invertido mucho en UWP y ha logrado un éxito comercial con UWP, ¿tal vez plantillas para WinUI (escritorio) y WinUI (tienda)? Solo necesita seguir los medios tecnológicos para tener una idea de cuán mal se ve a UWP como una plataforma de desarrollo.

@VagueGit
"Tenemos una aplicación para UWP que queremos migrar a WinUI. No usamos la api de Win32, solo apuntamos al escritorio y no queremos usar la tienda. ¿Cómo encaja eso?"

Entonces, ¿desea migrar una UWP a WinUI 3 e implementarla fuera de la Tienda? Una pregunta ingenua: ¿probaste la descarga lateral de MSIX? ¿Alguna razón además de la Tienda que le impida usar UWP?

@VagueGit
"Sabemos que existe un mercado para las aplicaciones empresariales Win64".

Una pregunta, Win64 significa muchas cosas. por ejemplo, las aplicaciones se compilan para x64. ¿Qué significa Win64 para ti?

@ marb2000 UWP tiene poca compatibilidad con los informes comerciales. Creemos que el cambio de marca podría ayudar a impulsar el desarrollo de herramientas de terceros, como los redactores de informes. Tuvimos una jugada con carga lateral, pero no fue posible para nosotros hasta el 20H1, ya que la carga lateral no estaba habilitada de forma predeterminada.

Creemos que Win64 es el camino a seguir en Windows. Micro $ ha intentado en el pasado presentar Win32 como heredado sin éxito y ahora está volviendo a esa posición. Pero en última instancia, Win32 tiene que desaparecer, a nuestro juicio (lo digo yo mismo después de 30 años de desarrollo de Win32). Hemos logrado superar la mayoría de las limitaciones de UWP para ofrecer una aplicación empresarial que las empresas comprarán. Nos preocupa que otra iteración de UWP tenga una tracción limitada sin un cambio de marca.

Como muestra la confusión de @ marb2000 , el término Win64 ya se utiliza (mal). También lo he señalado antes.

Estoy de acuerdo en que podría ser necesario un cambio de marca, pero Win64 es una forma terrible de hacerlo. Hasta que haya algo oficial, debe usar el término UWP para que todos lo entiendan.

@sylveon UWP es entendido por todos como un fracaso. Nos gusta, pero a pocos otros les gusta. Es por eso que el cambio de marca es importante. ¿Qué opinas de WinUI (Deskop) o WinUI (Store) como plantillas de proyecto?

WinUI (Store) no es bueno porque también puede enviar aplicaciones Win32 en la tienda o enviar aplicaciones UWP fuera de la tienda. Sin embargo, WinUI (escritorio) es bueno.

@sylveon WinUI (Store) no excluye otros proyectos dirigidos a la tienda. Simplemente significa que desea comenzar con el conjunto de capacidades que permiten el lanzamiento a través de la tienda.

Ya es bastante malo para confundir a los principiantes.

Esto no está destinado a ninguna persona en particular en este hilo, sino a mi propia opinión como desarrollador de aplicaciones de escritorio / propietario de la empresa.

Nunca me dejo llevar por el nombre de algo. Solo me importa qué características tiene y qué tan bien es compatible.

Yo diría que también hay muchos desarrolladores (incluido yo) que se emocionan cuando usamos términos como MAUI, pero se decepcionan inmediatamente cuando nos damos cuenta de que sigue siendo la misma base de código. El cambio de marca sugiere "oye, estamos construyendo esta cosa nueva que comienza desde una base de código que es completamente diferente a la que te ha bloqueado de xyz". Lo que ME ENCANTA ver es una enorme lista de características que cambiaron y compensaron las luchas que yo o cualquier otra persona teníamos.

Las plataformas se desarrollan con el tiempo como lo hace cualquier producto o marca. Encuentro consuelo en marcas y nombres que han existido durante décadas porque implica automáticamente LTS. Aunque me doy cuenta de que los cambios de nombre a veces son una necesidad, también recuerdan a los desarrolladores el abandono (Silverlight). Existen muchos modelos de automóviles que tuvieron años en los que estuvieron plagados de problemas, pero terminaron convirtiéndose en marcas amadas y respetadas. Hay mucho que decir con familiaridad, incluso si no le gustan las experiencias anteriores, porque sabe qué esperar. Mientras se resuelvan los problemas, eso es realmente lo que cuenta.

Creo que hay al menos dos públicos que deben tenerse en cuenta; desarrolladores y usuarios de productos finales. Como desarrollador / propietario de un negocio, si tengo un cliente que necesita una aplicación y se ha visto afectado por los nombres de la tecnología subyacente, es mi trabajo inculcarles la confianza de que el producto representado por el nombre ha madurado y lo que les preocupa en el pasado se ha actualizado. Por otro lado, si digo "mire, existe esta nueva gran cosa llamada WinUI o MAUI" y ya poseen los productos WPF o UWP o Xamarin que desarrollamos para ellos, una respuesta previsible de ellos es "Oh, genial, ahora nuestras aplicaciones están escritos en 2,3 o 4 tecnologías diferentes ”. Aquí es donde tengo que venderlos. Teniendo en cuenta que todos los clientes son diferentes, voy a encontrar un retroceso si deja el nombre como está o lo cambia.

Lo que es importante al final (para mí) es que tenemos las herramientas que necesitamos para escribir aplicaciones atractivas y ricas en funciones que tengan LTS. Me emociono cuando veo que un producto alcanza los plazos y puedo leer la nueva función y la lista de resolución de problemas cuando se lanza el producto. Me ha encantado esto de NetCore / Net5 (cambio de nombre LOL) desde 2016. (Por cierto, tratar de decirles a mis clientes que .Net5 es lo que planeamos apuntar un año después de que los convencí de que se cambiaran a NetCore tampoco es fácil).

En este momento, solo quiero avanzar rápidamente hasta un punto en el que pueda escribir una aplicación de escritorio con dialecto XAML y obtener el mismo rendimiento de renderizado que ofrece UWP / WinUI (sin la zona de pruebas de UWP). Por esa razón y debido a la vista previa de septiembre lanzada, voy a comenzar a conducir las pruebas de manejo de Avalonia. Me encantan las similitudes de WPF mientras escucho sobre el rendimiento de renderizado a través de SkiaSharp.

Va a ser emocionante en un par de años cuando las opciones para el desarrollo de la interfaz de usuario se hayan estabilizado. Pueden nombrar las plantillas de proyectos como quieran, no cambiará mi opinión sobre la falta de funciones.

Los aprecio a todos.

Entiendo lo que dice jtbrower en su correo electrónico. Su empresa, como la nuestra, es una de las pocas que siguió con éxito el camino xaml. No necesitamos estar convencidos de los beneficios.

Pero por bueno que sea, xaml fue un desastre para Micro $. La abrumadora mayoría de los desarrolladores se quedaron con WinForms o se lanzaron por completo al desarrollo web. Desde UWP, el éxodo de desarrolladores empeoró.

Para que las tecnologías xaml sean sostenibles, Micro $ debe ganar esos millones de desarrolladores a los que no han podido incorporar. Para esos desarrolladores, proveedores de herramientas y medios tecnológicos, UWP es un callejón sin salida. Otra iteración de UWP no los ganará.

@VagueGit, pero los desarrolladores están lo suficientemente interesados ​​en saber que un producto renombrado es el mismo. Ellos conocen MAUI como un Xamarin Forms renombrado. De hecho, parecen ir tan lejos al decir que MAUI era un nombre robado. No creo que puedas motivar a un desarrollador típico con un cambio de nombre. Todos queremos funciones, ¿no? ¿No preferirías que UWP permitiera múltiples Windows o permitiera la plena confianza? Si hicieran ambas cosas, todos podríamos apuntar a UWP y tal vez mantener la zona de pruebas para las aplicaciones de la tienda. ¡Solo estoy soñando en voz alta lo que realmente me emocionaría! ¡¡Características!!

Absolutamente de acuerdo con usted jtbrower. También agradezco su ayuda y espero que otros critiquen sus ideas. Pero, ¿cómo informar a los desarrolladores y proveedores de herramientas que hay dos UWP diferentes, Store y Desktop?

Entonces, por supuesto, aquellos que quieran continuar por la ruta de UWP pueden comenzar con la plantilla de la tienda UWP, pero aquellos que quieran un escritorio de 64 bits, no un espacio aislado y de plena confianza ... bueno, eso no es UWP, ¿verdad?

UWP se ve en el mercado como paralizado. Todos, excepto nosotros, los fanáticos de UWP, abandonamos la UWP cuando la propia Micro $ se retiró de la creación de sus propias aplicaciones en UWP.

El mercado de desarrollo no está atento a los desarrollos en UWP. El escritorio de 64 bits, sin espacio aislado y de plena confianza, es mucho más que un cambio de nombre; es un paradigma diferente. Pero si todavía se llama UWP, pasará desapercibido para quienes hayan cancelado UWP.

@VagueGit Me alegra que haya tenido éxito con UWP. La asignación de nombres es difícil, y el hecho de que la llamemos la "Plataforma universal de Windows" y no sea realmente sostenible para la gran mayoría de los desarrolladores de Windows hace que, bueno, no sea muy "universal". Un resumen preciso de Project Reunion es arreglar esto y hacer que todos los aspectos de UWP sean realmente accesibles para todos los desarrolladores de Windows.

Estoy de acuerdo en que UWP tiene un mal nombre, si escribe la frase "UWP is" en un motor de búsqueda, la primera sugerencia automática que le darán Bing o Google es "UWP is dead". Sin embargo, creo que @ marb2000 tiene razón en que deberíamos seguir usando el nombre, a pesar del equipaje que conlleva.

Con eso dicho...

Hoy en día, muchos aspectos de los proyectos de escritorio podrán usar diferentes partes de lo que solíamos definir como "UWP":

1. La pila de UI (también conocida como WinUI3)
2. Embalaje MSIX
3. Recursos MRT

Una vez que se elimine CoreApplication, la única diferencia entre UWP y Desktop será realmente el modelo de espacio aislado que elija para su aplicación y los dispositivos a los que pueda dirigirse.

Hemos hablado de hacer modificaciones a las plantillas del proyecto y tener una experiencia similar a la de un asistente que describa esto con mayor precisión.

@JeanRoca es el primer ministro que está impulsando esto y puede tener más información que pueda compartir

Me gusta la idea de la plantilla de escritorio WinUI. Más apropiado que Win32 y con visión de futuro. Es la plantilla con la que comenzaríamos, mientras que Win32 sugirió una restricción de 32 bits. Es de esperar que WinUI Desktop obtenga algo de tracción en los medios y entre los desarrolladores.

Cuando se lanza una aplicación para UWP fuera de la tienda, el paquete es .appinstaller. Si actualizamos esa aplicación a Win UI Desktop, el paquete de instalación cambia de appinstaller a msix.

Suponiendo que mantenemos los mismos detalles dentro del paquete de la aplicación y mejoramos la versión de manera apropiada, ¿reconocerá Windows que se trata de una nueva versión de la misma aplicación y conservará los datos locales, o la instalará como una aplicación diferente?

Según tengo entendido, WinUI 3.0 nunca se consumirá desde .NET Framework <= 4.8. Entonces, si estamos hablando de WinUI, estamos hablando de .NET Native o .NET 3.1 / 5 + (u otro conjunto de enlaces).

¿Alguna sugerencia sobre cómo avanzar / preguntar más sobre el empaquetado del marco para .NET 5 (o supongo que 6 en este punto)? Abrí un problema y no obtuve respuesta. Empaquetar .NET 5 en la aplicación no es un principio.

@stevenbrix

Una vez que se elimine CoreApplication, la única diferencia entre UWP y Desktop será realmente el modelo de espacio aislado que elija para su aplicación y los dispositivos a los que pueda dirigirse.

Desafortunadamente, otra gran diferencia es que los desarrolladores de .NET se ven obligados a utilizar C ++ para API como DirectX, cuyo equipo claramente se niega a hacerlas compatibles con UWP a pesar de estar basadas en COM.

Y en el proceso, regrese a los días de productividad de escribir MIDL manualmente con una agradable experiencia de bloc de notas y copiar archivos, aparentemente el equipo de Windows no puede dejar de lado la experiencia de desarrollo de ATL, en lugar de proporcionar una experiencia de NET para los flujos de trabajo de C ++. C ++ / CX se estaba acercando demasiado a C ++ Builder, por lo que tuvo que eliminarse en nombre de las cosas de ISO, que con suerte podríamos obtenerlas en C ++ 23 y en 2025 en VS.

Dudo que alguien se preocupe por UWP para entonces, a menos que se establezca una experiencia de desarrollo adecuada para eliminar todos estos errores.

También nos arrojan problemas de GitHub con respecto a qué equipo enviar comentarios es una forma muy rápida de perder interés. Parece que me preocupo demasiado.

Las API de DirectX no se pueden modificar para la compatibilidad con WinRT porque sería una ruptura significativa de la API para los consumidores existentes, y eso simplemente no puede suceder.

Hay varios contenedores administrados disponibles para DirectX, como TerraFX, que es un Vortice, que es un contenedor de API de estilo más C #.

En cuanto a CX, tenía que desaparecer. Las extensiones de lenguaje específicas del compilador son malas y están mal vistas. Dificulta significativamente la portabilidad del código, a menudo se queda atrás en términos de compatibilidad con el estándar C ++ y requiere una integración vertical completa de las bibliotecas existentes. La alternativa, WRL, era muy difícil de usar y demasiado detallada. Por lo tanto, no es sorprendente que mucha gente (incluida la división DX) no quisiera escribir API de WinRT.

C ++ / WinRT es una solución mucho mejor, es desafortunado que tuviera que traer de vuelta IDL (pero un mal necesario actualmente). El equipo de C ++ ha estado haciendo un trabajo mucho mejor en el soporte de estándares que antes, por lo que no sería sorprendente si realmente obtenemos metaclases antes de que C ++ 23 esté finalizado, lo que debería mejorar radicalmente la UX del desarrollador.

@sylveon

No se sorprenda de que la comunidad de desarrolladores de Windows ignore todo lo que surja de Redmond con tal justificación para la caída de la productividad.

Lo mismo estaba sucediendo con CX ... no se usó en gran medida porque a los desarrolladores de C ++ no les gustan las extensiones de lenguaje propietarias.

Suponiendo que mantenemos los mismos detalles dentro del paquete de la aplicación y mejoramos la versión de manera apropiada, ¿reconocerá Windows que esta es una nueva versión de la misma aplicación y preservará los datos locales, o la instalará como una aplicación diferente?

@VagueGit , esta es una gran pregunta. Al final del día, la tecnología para instalar aplicaciones de escritorio y UWP es la misma. ¿Siento que la respuesta es sí? Creo que a partir de los SDK más recientes, incluso las aplicaciones para UWP tienen la extensión .msix (podría estar equivocado, así que no me cites). Estoy seguro de que podrías probar esto localmente y averiguarlo. @adambraden para tu información.

¿Alguna sugerencia sobre cómo avanzar / preguntar más sobre el empaquetado del marco para .NET 5 (o supongo que 6 en este punto)? Abrí un problema y no obtuve respuesta. Empaquetar .NET 5 en la aplicación no es un principio.

@lmcdougald Creo que sé a qué problema te refieres (pero no puedo encontrarlo). Habrá uno, pero imagino que estará en el marco de tiempo .net6. Todos saben que esto es algo que debe hacerse.

Y en el proceso, regrese a los días de productividad de escribir MIDL manualmente con una agradable experiencia de bloc de notas y copiar archivos, aparentemente el equipo de Windows no puede dejar de lado la experiencia de desarrollo de ATL, en lugar de proporcionar una experiencia de NET para los flujos de trabajo de C ++. C ++ / CX se estaba acercando demasiado a C ++ Builder, por lo que tuvo que eliminarse en nombre de las cosas de ISO, que con suerte podríamos obtenerlas en C ++ 23 y en 2025 en VS.

También nos arrojan problemas de GitHub con respecto a qué equipo enviar comentarios es una forma muy rápida de perder interés. Parece que me preocupo demasiado.

@pjmlp Agradezco tu honestidad y pasión. No podría estar más de acuerdo en que la experiencia actual de C ++ es insatisfactoria. Hemos hecho bastantes cosas para que la experiencia de C ++ se parezca más a .NET, pero como mencionó @sylveon , tienen un costo. Eventualmente decidimos que si queremos dedicar esfuerzos de ingeniería a hacer que C ++ sea grandioso, deberíamos dedicarlo a impulsar el estándar C ++. Es lamentable que las metaclases sean una salida, y estamos discutiendo formas de mejorar la experiencia en el ínterin, porque estoy de acuerdo contigo en que no podemos esperar tanto.

Gracias por la respuesta. Estoy contento con “todos saben que esto es algo que debe hacerse” y viviré con un binario inflado durante un año más o menos.

@stevenbrix y @VagueGit : aún debería poder usar un archivo de instalación de aplicaciones para sus paquetes msix. el archivo appinstaller no es más que un archivo json que proporciona el uri a sus paquetes. Como mencionó escenarios empresariales, puede personalizar los uri del instalador de aplicaciones de manera adecuada para las ubicaciones internas, o hacerlos diferentes también para el acceso externo, todo depende de su CDN. Con respecto al control de versiones, sí para las aplicaciones empaquetadas si la identidad del paquete es la misma, entonces la instalación de una nueva versión tendrá acceso a los datos de la aplicación existente.

@stevenbrix @VagueGit Responderé con la información que tengo actualmente sobre la experiencia de asistente. Todavía soy muy nuevo en este puesto, así que siéntete libre de tomar todo lo que digo con un grano de sal. Dicho esto, mi equipo actualmente está impulsando los esfuerzos en Windows Template Studio . Actualmente, esta aplicación le permite crear una nueva aplicación WPF o UWP a partir de plantillas existentes en nuestro asistente con las páginas y los marcos que desee.

El objetivo y el plan actual de esta aplicación en el futuro es unificar y mejorar la experiencia de desarrollo para todos los usuarios. Actualmente estamos desarrollando plantillas para aplicaciones de escritorio con WinUI 3. Puede encontrar el problema de seguimiento aquí . También estamos discutiendo hacer lo mismo para UWP para que nuestros usuarios puedan migrar fácilmente sus proyectos cuando llegue el momento. Todavía no sabemos exactamente cómo funcionará esto, pero nuestro objetivo será unificar y simplificar la experiencia tanto como sea posible. ¡Espero que ayude!

Lo mismo estaba sucediendo con CX ... no se usó en gran medida porque a los desarrolladores de C ++ no les gustan las extensiones de lenguaje propietarias.

Los aman en clang, GCC, Intel. xlCC, PGI, CUDA, C ++ Builder y la plétora de plataformas integradas.

Obviamente, CX fue asesinado debido a la política que no puede aceptar un entorno RAD de C ++ procedente de Microsoft y, en cambio, hacer que todos hagamos MDIL / ATL con una experiencia similar a la de un bloc de notas.

Los evito a toda costa sin importar el compilador. Especialmente cuando dicha extensión propietaria es un lenguaje completamente diferente por sí solo.

Los evito a toda costa sin importar el compilador. Especialmente cuando dicha extensión propietaria es un lenguaje completamente diferente por sí solo.

Entonces, ¿por qué codificar contra una interfaz de usuario patentada como WinUI? Simplemente use estándares abiertos como X Windows en su lugar.

... como si eso fuera utilizable en Windows. Evito las extensiones de compilador porque quiero compiladores de objetivos múltiples (Clang y MSVC) para la validación del cumplimiento de estándares y quiero usar estándares C ++ más nuevos.

Mi código usa C ++ 20. Muchas extensiones de lenguaje carecen de soporte para C ++ 17 o lo consiguieron muy tarde. Esta situación se repetirá con C ++ 20 (o empeorará ya que C ++ 20 tiene muchas más cosas nuevas que 17). Por ejemplo, no puede mezclar C ++ 20 ( /std:c++latest ) y CX ( /ZW ), obtendrá un error del compilador diciendo que los dos conmutadores son incompatibles.

NVCC tardó hasta este año en admitir C ++ 17 en el lado del dispositivo. No es un buen aspecto.

No quiero arrinconarme en el que la extensión de idioma que uso no se pueda utilizar con un estándar más nuevo, pero también necesito una nueva función estándar.

Por las razones anteriores, las evito. Si hacemos una regresión de la experiencia del desarrollador de WinUI C ++ a una extensión de lenguaje, pasaré a un marco de GUI alternativo.

@sylveon Tu C ++ 20 perfectamente portátil para WinUI es completamente inútil fuera de Windows, diviértete con Qt sin extensiones también.

Porque no queda nada que valga la pena usar para los usuarios de escritorio de C ++.

Gracias por confirmar que la política sin sentido es lo que mató a CX.

Sugerencia de ser amistosos el uno con el otro. No puedo comentar sobre los argumentos técnicos de C ++ y no juzgaré quién tiene razón.
El punto es que frases como go have fun with X no están creando un ambiente amigable y colaborativo aquí. @stevenbrix y otros, por favor intervengan si es necesario.

Gracias @hansmbakker ☺️

@pjmm y @sylveon Aprecio la conversación apasionada y honesta, es genial tener clientes como tú que se preocupan.

Ambos puntos son extremadamente válidos, y creo que el mundo es lo suficientemente grande como para que ambos tengan razón.

@pjmlp no estamos satisfechos con la experiencia actual para c ++, y reconocemos que tenemos que hacer algo antes de las metaclases de c ++. Hemos tenido algunas discusiones sobre c ++ / winrt sin idl, y @kennykerr y @ Scottj1s hicieron una charla sobre compilación al respecto. La mayoría de los problemas que tuvimos estaban relacionados con la integración con WinUI, ya que nuestro compilador requiere metadatos. Queremos volver a visitar este flujo de trabajo para ver si podemos tener una historia coherente que mejore la experiencia general del desarrollador. En lugar de traer de vuelta C ++ / Cx, ¿le interesaría una versión libre de idl de c ++ / winrt?

Solo para establecer expectativas, no esperaría ver mucho progreso aquí en 2020.

Me interesaría mucho un C ++ / WinRT libre de IDL.

La experiencia IDE tampoco es la mejor. Por ejemplo, no podemos crear una devolución de llamada de evento desde el editor XAML como podemos hacerlo con C # (el menú desplegable de creación de nueva devolución de llamada no hace nada). Navegar a la definición desde el editor XAML tampoco funciona.

Otros problemas con él son los diversos errores del compilador XAML que llené en este repositorio, lo que me hace requerir soluciones alternativas que no son necesarias en otros lenguajes compatibles.

@stevenbrix , me gustaría agregar mi voz a C ++ / WinRT sin IDL (y ciertamente no quiero volver a C ++ / CX). Escribimos software multiplataforma y lo compilamos tanto con MSVC como con LLVM (incluso en Windows), por lo que C ++ es muy importante para nosotros.

@stevenbrix ,

@pjmlp no estamos satisfechos con la experiencia actual para c ++, y reconocemos que tenemos que hacer algo antes de las metaclases de c ++. Hemos tenido algunas discusiones sobre c ++ / winrt sin idl, y @kennykerr y @ Scottj1s hicieron una charla sobre compilación al respecto. La mayoría de los problemas que tuvimos estaban relacionados con la integración con WinUI, ya que nuestro compilador requiere metadatos. Queremos volver a visitar este flujo de trabajo para ver si podemos tener una historia coherente que mejore la experiencia general del desarrollador. En lugar de traer de vuelta C ++ / Cx, ¿le interesaría una versión libre de idl de c ++ / winrt?

Solo para establecer expectativas, no esperaría ver mucho progreso aquí en 2020.

Lo que solo demuestra lo mala que fue toda esta idea con C ++ / WinRT para empezar, reduciéndola sin tener en cuenta nuestra caída de productividad.

Para poner esto en perspectiva, desarrollador de mucho tiempo cuya experiencia como desarrollador de Windows se remonta a Windows 3.0, y hoy en día C ++ es principalmente relevante para ser utilizado junto con aplicaciones basadas en .NET, nunca solo.

Las herramientas de Borland eran mi pan y mantequilla hasta que, por varias razones conocidas por los antiguos desarrolladores de Windows, el camino a seguir terminó siendo migrar a los compiladores de Microsoft.

Visual C ++ nunca fue _Visual_ como C ++ Builder, ni siquiera con C ++ / CLI, dada su falta de integración con la compilación Forms y AOT.

C ++ / CX parecía que Microsoft finalmente lo había conseguido, 25 años después tendríamos los mismos flujos de trabajo de productividad que usar Delphi / C ++ Builder juntos.

En cambio, lo que obtuvimos como un movimiento político para matar C ++ / CX sin tener en cuenta nuestra mano caída productiva agitando la responsabilidad de las características faltantes a ISO C ++ y WG 21, como si todo lo que el equipo de Visual C ++ nos está quitando fuera a ser aceptado por el GT 21.

E incluso si las características necesarias eventualmente serán adoptadas por ISO C ++, ¿será 2023, 2026, ....? Y luego está el punto de cuándo esas características estarán realmente disponibles para los desarrolladores de Windows, solo mire el soporte de los módulos. Estamos tardando unos años interminables en alcanzar la paridad con lo que C ++ / CX nos ha estado ofreciendo desde que se lanzó Windows 8 en 2012.

Entonces, dado que para 2020 no veremos ninguna mejora, ya estamos hablando de 9 años aquí, así que discúlpeme si tiendo a enojarme un poco por cómo se ha manejado todo esto, además de los otros problemas que tenemos. para lidiar con la falla de UWP, Reunion, reinicio del ecosistema .NET, mientras nos piden que codifiquemos como si fuera el año 2000 con una experiencia básica de bloc de notas MIDL y una sopa de plantillas interminable como ATL.

Así que sí, ya sea una versión de C ++ / WinRT libre de IDL, o al menos una experiencia IDL con soporte completo de Intellisense / Intelicode y sin tener que copiar archivos manualmente. Sin embargo, eso no quitará la experiencia de ATL del propio código C ++.

Desde el punto de vista del desarrollo de .NET / C ++, no me importa viajar en el tiempo al pasado de los frameworks de Microsoft, sino cómo podría verse si el punto de vista de C ++ RAD se tomara más en serio, desafortunadamente con la forma en que C ++ / La historia de WinRT se ha gestionado, y todo lo demás que ahora va con retroceso de UWP, me pregunto a dónde ha ido "desarrolladores, desarrolladores, desarrolladores".

Lo siento si todavía se siente un poco raro, pero así es como me siento acerca de la caída de mi productividad cuando necesito salir de .NET a C ++, en nombre de algo de pureza ISO que la mayoría de los compiladores de C ++ no hacen de todos modos.

C ++ sigue siendo muy relevante de forma independiente. Muchas aplicaciones están escritas en C ++ sin formato sin que se ejecute ningún código administrado. De hecho, todo el tiempo de ejecución de UWP y el marco XAML / WinUI es C ++ nativo. Una aplicación para UWP escrita en C ++ no tiene (afortunadamente) ningún lenguaje administrado involucrado.

Yo diría que si siente la necesidad de pasar a C ++ en .NET, debería preguntarse por qué y tratar de abordar esos problemas directamente dentro de .NET. ¿Rendimiento? Utilice los tipos de tramo, stackalloc e intrínsecos vectoriales. ¿DirectX, API nativas o COM? Utilice un enlace como TerraFX. ¿Interactuar con una biblioteca solo en C ++? Vuelva a implementar lo que necesita en .NET.

.NET está mejor sin C ++, y C ++ está mejor sin .NET.

No creo que las plantillas en cppwinrt sean tan malas. Lo que más me molesta es la necesidad de generar código y el horrible tiempo de compilación que produce.

@sylveon Fácil, debido a las API que el equipo de Windows se niega a poner a disposición como UWP y que no cuentan las vinculaciones de terceros, no todo el mundo tiene la suerte de contar con un departamento legal que deja pasar todo, sin consideraciones de licencia y problemas de soporte futuro.

Borland (ahora Embarcadero) y The Qt Company han demostrado cómo hacerlo, depende de Microsoft decidir qué tan relevante quieren mantener la plataforma.

Intente ver qué tan lejos llegará con ISO C ++ en macOS, iOS, Android, GUI de ChromeOS.

De todos modos, parar aquí, no tiene sentido.

@pjmlp tenemos aplicaciones multiplataforma con millones de líneas de ISO C ++ que funcionan bien en iOS / macOS / Windows. C ++ es el único lenguaje que se puede usar cuando se preocupa por el rendimiento y / o la duración de la batería. Las extensiones de C ++ no son buenas para nosotros ya que usamos múltiples compiladores (que obviamente no implementan las extensiones de los demás).
Hemos usado C ++ / CLI anteriormente y es una molestia. Las restricciones como que los miembros de la clase solo permitan punteros C ++ sin formato dificultan el almacenamiento de punteros inteligentes. El tiempo de compilación es largo (los cambios de un solo carácter requieren 5 minutos de tiempo de combinación de MD).
C ++ incluye requiere encapsulado para cambiar pragma administrado / no administrado
El compilador es una versión diferente para C ++ / CLI en comparación con C ++ (y me dijeron en la compilación que el compilador C ++ / CLI no sería compatible con versiones posteriores a C ++ 17, lo cual es un problema cuando se incluyen encabezados de bibliotecas que usan C ++ 20 funciones).
Lo que estoy tratando de decir es que no tenga múltiples esfuerzos en competencia. Siga el estándar y trabaje con eso. Microsoft está en el comité de C ++, ellos ayudan a impulsar el estándar hacia adelante, este debería ser el foco, no propietario, bloqueado en extensiones.

¿Podríamos tener un compilador xaml, como xaml.exe para compilar archivos xaml, similar a midl.exe, cl.exe o link.exe? Sería muy útil crear una canalización automática para la aplicación winui.

A veces, no queremos usar Visual Studio para hacer el desarrollo, tal vez usando cualquier editor que queramos, pero mantenemos una canalización de compilación separada. Parece que la aplicación winui xaml es una parte especial y parece que todavía no existe una herramienta de línea de comandos para compilarla.

Esto es necesario para escenarios como cmake: https://github.com/microsoft/ProjectReunion/issues/58

¿Podríamos tener un compilador xaml, como xaml.exe para compilar archivos xaml, similar a midl.exe, cl.exe o link.exe? Sería muy útil crear una canalización automática para la aplicación winui.

@sammi, ¿el # 1433 resume una solución plausible para lo que estás buscando?

¿Podríamos tener un compilador xaml, como xaml.exe para compilar archivos xaml, similar a midl.exe, cl.exe o link.exe? Sería muy útil crear una canalización automática para la aplicación winui.

@sammi, ¿el # 1433 resume una solución plausible para lo que estás buscando?

@jtbrower , esa es exactamente la característica que estoy buscando, ¡gracias!

Ciertamente es una vista previa, y eso significa que no debería esperar mucho, pero la vista previa 2 de WinUI 3 fue decepcionante para mí.

Mi mayor necesidad está en el área del diseño XAML. Me sorprendió bastante el hecho de que el diseñador XAML no funcionó en absoluto, y hasta ahora no he encontrado información clara sobre cuándo lo hará.

Sí, estoy de acuerdo en que el diseñador XAML actual en Visual Studio es muy lento y se rompe cuando uno cambia cosas en tiempo real que realmente no deberían romperlo. Por ejemplo, cambiando Height="*" a "Auto" o un 100. (la ventana de error muestra alrededor de 10 errores - garabatos en abundancia, y tiene que reconstruir el proyecto)

Para ser claros, realmente no uso al diseñador para diseñar, solo quiero tener una idea si mi diseño parece que lo había imaginado antes de pasar por el proceso de construcción. Si es más fácil, si el diseñador fue simplemente "Ver solo", y se actualizó cuando modifiqué el XAML (sin fallar), estaría bien para mí, ya que no uso la GUI para cambiar el XAML ... o muy raramente . Realmente, lo que WindowsCommunityToolkit hace con la fuente XAML que permite al usuario cambiar la fuente y ver la salida en tiempo real es lo suficientemente bueno para mis propósitos.

Dicho todo esto, WinUI tiene una gran idea: desacoplar todas estas cosas "fáciles" del sistema operativo y dejar que el trabajo del desarrollador evolucione mucho más rápido, y podemos agrupar las dependencias con la aplicación para evitar tener que actualizar 1Bn de dispositivos. para que puedan ejecutar nuestras nuevas y geniales cosas.

Espero que Project Reunion también termine separando totalmente la GUI del contenedor de la aplicación. UX similar a UWP sin sandbox / límites sería un gran paso adelante.

Pero, ¿cuándo podemos tener un diseñador XAML que funcione de nuevo ... por favor?

Creo que la recarga en caliente ha desaprobado en su mayoría el propósito de "solo lectura" del diseñador XAML.

Pero estamos hablando de herramientas WinUI aquí. La recarga en caliente y el árbol visual en vivo tampoco funcionan para WinUI.

Lo que quise decir con el diseñador de solo vista fue "Podría conformarme con eso si fuera algo que pudiéramos incluir en una próxima vista previa".

Podría estar equivocado (Y, por favor, Dime si lo estoy), pero ahora mismo, la única forma de ver tu interfaz de usuario en WinUI es compilarla y ejecutarla.

Pero estamos hablando de herramientas WinUI aquí. La recarga en caliente y el árbol visual en vivo tampoco funcionan para WinUI.

Lo que quise decir con el diseñador de solo vista fue "Podría conformarme con eso si fuera algo que pudiéramos incluir en una próxima vista previa".

Podría estar equivocado (Y, por favor, Dime si lo estoy), pero ahora mismo, la única forma de ver tu interfaz de usuario en WinUI es compilarla y ejecutarla.

Hola @ ericleigh007, ¿has tenido la oportunidad de ver nuestra última versión de WinUI 3 Preview 3? Recientemente agregamos muchas mejoras de herramientas como IntelliSense, Hot Reload, Live Visual Tree y Live Property Explorer. Puede consultar las notas de la versión aquí y obtener la última vista previa aquí . Estoy interesado en tus pensamientos, así que no dudes en comunicarte con nosotros.

@JeanRoca Desafortunadamente, ponerse al día con la experiencia de desarrollo de C ++ / CX no fue una de esas mejoras en las herramientas. No espere mucho amor de los desarrolladores por WinUI cuando las herramientas propuestas de C ++ se sientan como volver a 2000, escribir archivos IDL en el bloc de notas (sin ningún soporte de editor) y copiar archivos manualmente.

Me hace permanecer en .NET tanto como puedo, o simplemente seguir usando C ++ / CX a pesar de las advertencias para pasar a C ++ / WinRT.

Gracias por la actualización; Lo intentaré hoy e informaremos. 🤞

Enviado desde Mail https://go.microsoft.com/fwlink/?LinkId=550986 para Windows 10

De: JeanRoca [email protected]
Enviado: miércoles 18 de noviembre de 2020 4:41 a.m.
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: Eric [email protected] ; Mencione menció[email protected]
Asunto: Re: [microsoft / microsoft-ui-xaml] Herramientas y experiencia para desarrolladores de WinUI 3.0: se requiere entrada (n. ° 1045)

Pero estamos hablando de herramientas WinUI aquí. La recarga en caliente y el árbol visual en vivo tampoco funcionan para WinUI.

Lo que quise decir con el diseñador de solo vista fue "Podría conformarme con eso si fuera algo que pudiéramos incluir en una próxima vista previa".

Podría estar equivocado (Y, por favor, Dime si lo estoy), pero ahora mismo, la única forma de ver tu interfaz de usuario en WinUI es compilarla y ejecutarla.

Hey @ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = jha7IQJyg% 2BKEZK10fKvIQJyg% 2BKEZST10fKvIQJyg% 2BKEZST10fKvIQJyg% 2BKEZST10fKvIQJyg Recientemente agregamos muchas mejoras de herramientas como IntelliSense, Hot Reload, Live Visual Tree y Live Property Explorer. Puede consultar las notas de la versión aquí https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160082691% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 y sdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3D y reservado = 0 y obtener la última vista previa aquí https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-us% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F y datos = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 y sdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc% 3D y reservado = 0 . Estoy interesado en tus pensamientos, así que no dudes en comunicarte con nosotros.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012 y datos = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 y sdata = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D y reservado = 0 , o darse de baja https: //eur05.safelinks.protection.outlook .com /? url = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ y datos = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 y sdata = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks% 2FfmXT0Bc% 3D y reservado = 0 .

-No existe un editor / método wysiwyg que funcione con winui3 c ++ (escritorio) en este momento, ¿verdad?

¿Microsoft también está logrando alienar a los usuarios de C ++ / CX? Todo esto no está nada bien. Cualquiera que haya adoptado la tecnología que Microsoft impulsaba hace unos años para UWP, ya sea que .net o c ++ tenga problemas ahora sin el apoyo de Microsoft.

Parece que WinUI 3 solo se ocupa de aplicaciones de escritorio escritas en WPF, pero se darán cuenta rápidamente de que UWP no tiene todas las características de WPF y aún menos características de WinUI. Todos se sentirán frustrados, lo cual es un mal lugar para iniciar WinUI 3.

@robloo Como alguien que solía abogar por UWP me perdieron, es WPF y Win32 hasta que resuelvan el lío.

C ++ / WinRT fue un movimiento político, y nos dijeron que simplemente lo hiciéramos y esperáramos hasta que ISO C ++ eventualmente brinde soporte de reflexión y metaclases, para que el equipo de Visual Studio replicara la experiencia C ++ / CX.

Como se mencionó, incluso la edición de archivos IDL no es diferente a usar el Bloc de notas sin procesar.

El hecho de que en .NET tuviéramos que soportar que Microsoft no pusiera todos los componentes de UWP a nuestra disposición, de alguna manera se podía superar con C ++ / CX ofreciendo una experiencia similar a C ++ / CLI. Ahora con C ++ / WinRT volvemos a ATL.

Luego, al leer las discusiones sobre temas de Reunión y la hoja de ruta de actualización, está claro que tomarán varios años para corregir el rumbo.

WPF y Win32 pueden ser viejos, pero están aquí y funcionan, sin tener otra reescritura y pérdida de funciones.

-No existe un editor / método wysiwyg que funcione con winui3 c ++ (escritorio) en este momento, ¿verdad?

El diseñador XAML funciona, pero en realidad no estaba diseñado para la edición wysiwyg para empezar. La recarga en caliente (que ahora funciona en la vista previa 3) funciona mejor.

El árbol visual en vivo y la vista de utilería en vivo funcionan muy bien en la vista previa 3. ¿Cuándo está programado que el diseñador esté disponible?

También noté que el diseñador de escritorio (WPF) (no UWP) solía trabajar en 2.4 (o algo así) pero ahora mis pruebas no lo ven funcionando nuevamente. ¿Me falta algo con el estado actual del diseñador?

Siento llegar tarde a la fiesta. @wjk lo clavó con su primer punto.

1. MSIX está muy bien, pero sigo usando el viejo MSI para instalar aplicaciones más complejas que requieren características que MSIX no admite. También estoy receloso de usar MSIX debido a lo costosos que son los certificados Authenticode requeridos.

Realmente aprecio el encanto de MSIX, pero este mandato de firma de certificado es un factor decisivo para mí. Necesito un asistente de instalación compatible con SCM adecuado que pueda utilizar para crear una experiencia clásica de instalación de escritorio. ¿Por qué no tomar las mejoras en MSIX y crear una nueva versión del instalador MSI sin los requisitos de certificación y de Microsoft Store para una experiencia de desarrollo más moderna? ¿Quizás esto es lo que se entiende por la función "Admite la implementación que no es de MSIX" enumerada en la hoja de ruta actual? Si es así, supongo que estoy atascado esperando 3.x, a menos que sea por algún milagro, eso lo convierte en una versión anterior. Espero eso porque los proyectos de VS Installer están trágicamente desactualizados y no son en absoluto amigables con el control de código fuente. 😓

@Chiramisu Estoy de acuerdo con el sentimiento, pero también estoy confundido: ¿qué pasa con la experiencia de descarga lateral + AppInstaller no es suficiente?

@Chiramisu ¿Has probado WiX ? Lo uso para todos mis instaladores basados ​​en MSI y funciona muy, muy bien. También hay una extensión de Visual Studio , por lo que puede tener proyectos de WiX que automatizan los diversos comandos de compilación.

@robloo Como alguien que solía abogar por UWP me perdieron, es WPF y Win32 hasta que resuelvan el lío.

C ++ / WinRT fue un movimiento político, y nos dijeron que simplemente lo hiciéramos y esperáramos hasta que ISO C ++ eventualmente brinde soporte de reflexión y metaclases, para que el equipo de Visual Studio replicara la experiencia C ++ / CX.

Como se mencionó, incluso la edición de archivos IDL no es diferente a usar el Bloc de notas sin procesar.

El hecho de que en .NET tuviéramos que soportar que Microsoft no pusiera todos los componentes de UWP a nuestra disposición, de alguna manera se podía superar con C ++ / CX ofreciendo una experiencia similar a C ++ / CLI. Ahora con C ++ / WinRT volvemos a ATL.

Luego, al leer las discusiones sobre temas de Reunión y la hoja de ruta de actualización, está claro que tomarán varios años para corregir el rumbo.

WPF y Win32 pueden ser viejos, pero están aquí y funcionan, sin tener otra reescritura y pérdida de funciones.

Para poder seguir el ritmo, ¿puedes darme una pista de qué edición IDL estás hablando con C ++ / WinRT? Por lo que he visto de co_await y otra sintaxis de C ++ 17, la complejidad parece haber aumentado en gran medida desde C ++ / CX.

¿SRA? ¿No es posible que, a menos que alguien cree algunos envoltorios realmente buenos en torno a eso, que C ++ / WinRT basado en las capacidades de C ++ 17 sea demasiado complejo y demasiado diferente de los diseños actuales? ¿No se podría mantener C ++ / CX lo suficiente como para crear una "envoltura excelente" para C ++ 17 para hacer que C ++ / WinRT sea razonablemente simple de usar y migrar?

(ahora alguien va a vincular a un artículo que muestra cómo se hace esto, y me voy a sentir tonto)

@lmcdougald No lo he probado todavía. Cabe señalar que mi proyecto en particular todavía está en .NET Framework 3.5. Sé que sé. No se me ha permitido actualizarlo todavía, así que estoy atascado con la tecnología del instalador que funcionará con este marco antiguo. 😖

@wjk Lo he

Amable

@Chiramisu Sí, WiX funciona con versiones antiguas de .NET Framework, y sí, también funciona con aplicaciones winforms. Dado que crea archivos MSI sin procesar, WiX puede instalar cualquier cosa, en cualquier lenguaje de programación. En cuanto a aprenderlo, empezaría con los tutoriales básicos . También me gustaría señalar cómo detectar si .NET está instalado y cómo ejecutar NGEN en archivos usando WiX , ya que está usando esas tecnologías en su aplicación. La extensión de Visual Studio también viene con una serie de plantillas de proyecto, para brindarle el código esqueleto correcto para agregar. (Nota: No use la plantilla Bootstrapper, ya que es un tema mucho más avanzado). ¡Espero que esto ayude!

@Chiramisu Estoy tan confundido con lo que estás buscando; me parece que estás buscando herramientas de empaquetado para tu proyecto actual y no para un proyecto WinUI 3.0.

Vale la pena señalar que .NET Framework 3.5 se puede empaquetar en un MSIX. Puede crear un paquete MSIX para su aplicación existente con un Proyecto de paquete en VS 2019, luego pasar por una transición larga sin problemas, pero es mucho trabajo:

WinUI 3.0 nunca admitirá oficialmente .NET 3.5 y probablemente nunca admitirá .NET Framework en ninguna versión. Comenzaría su modernización con el objetivo de actualizar a .NET 4.6 (o idealmente superior, 4.8 sería ideal) sin cambiar su proyecto de empaquetado existente. Si eso funciona sin problemas, comenzaría a transferir la funcionalidad a una biblioteca compartida de .NET Standard a la que hace referencia desde su aplicación .NET 4.6+ actualizada.

Una vez que la aplicación .NET 4.6 esté estable y probada, puede intercambiarla como una actualización automática para su proyecto de empaquetado de MSIX. Después del paso .NET Standard, puede crear un jefe de proyecto que use casi el mismo código de .NET Core 3.1 (o 5, pero creo que el estado LTS probablemente signifique algo para su organización). Nuevamente, pruebe y luego cambie el MSIX para usar esta versión.

Cambiar a WinUI desde WinForms en ese momento es una cuestión de aprender WinUI y volver a implementar la interfaz. Nuevamente, cree un nuevo encabezado de proyecto, implemente + haga referencia a la biblioteca .NET Standard, pruebe y luego cambie el paquete para usar esta versión.

Así es como haría la modernización sin crear proyectos muy divergentes en un momento dado. Daría prioridad a la configuración del paquete MSIX y los pasos de .NET 4.6 + .NET Standard, ya que estos le proporcionarán una gran cantidad de herramientas de ayuda y conexión con el ciclo de desarrollo de .NET moderno. Un cambio a .NET 5 apresuradamente suena como una mala idea para su organización a corto plazo, considerando que su ciclo de vida es 1/10 desde que existe .NET 3.5.

Para poder seguir el ritmo, ¿puedes darme una pista de qué edición IDL estás hablando con C ++ / WinRT? Por lo que he visto de co_await y otra sintaxis de C ++ 17, la complejidad parece haber aumentado en gran medida desde C ++ / CX.

¿SRA? ¿No es posible que, a menos que alguien cree algunos envoltorios realmente buenos en torno a eso, que C ++ / WinRT basado en las capacidades de C ++ 17 sea demasiado complejo y demasiado diferente de los diseños actuales? ¿No se podría mantener C ++ / CX lo suficiente como para crear una "envoltura excelente" para C ++ 17 para hacer que C ++ / WinRT sea razonablemente simple de usar y migrar?

(ahora alguien va a vincular a un artículo que muestra cómo se hace esto, y me voy a sentir tonto)

Debido a que C ++ normal no tiene la capacidad de extraer el tipo de metadatos necesarios para crear un archivo .winmd, debe escribir sus clases WinRT en un archivo .idl, además de .hpp y .cpp.

co_await es mucho menos complejo que escribir .then([=](Foo^ thing) { }) todas partes, es muy similar a la sintaxis await C

Aquí hay un ejemplo (idl + hpp + cpp) del proyecto de componente de tiempo de ejecución predeterminado:

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

Aquí hay un pequeño ejemplo de co_await:

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

Hola,

Estamos leyendo sus comentarios y tomando notas sobre los puntos débiles.

@ ericleigh007 XAML Designer salió porque después de recopilar los comentarios de los clientes, los principales puntos hoja de ruta de funciones . Según el plan de ingeniería actual, está fuera del 3.0 RTM, por lo que es posterior a 3.0.

@pjmlp Simpatizo con su pintura sobre C ++ / WinRT y la necesidad de agregar los IDL. C ++ / CX es mucho mejor en este aspecto. Mejorar la experiencia de C ++ / WinRT es otro tema que debemos abordar. Herramientas como Live Visual Tree y Hot Reload funcionan tanto en C # como en C ++, pero hay cosas específicas que solo afectan a C ++ y deben abordarse por separado. Según el plan de ingeniería actual, la solución del problema de IDL está fuera del 3.0 RTM.

@robloo , no nos

@Chiramisu Permítanme explicar qué significa "admite la implementación que no es MSIX". Hoy necesita instalar y ejecutar una aplicación de escritorio WinUI 3 usando MSIX. Esta capacidad se trata de eliminar esta necesidad. Para ejecutar una aplicación de escritorio WinUI 3, solo necesita duplicar en un .EXE, y eso es todo. Para instalar su aplicación, puede hacer una copia xcopy (no es necesario firmar nada). Básicamente, podrá utilizar otros sistemas de empaquetado e instalación como WiX.

@ marb2000 Gracias por reconocer el problema. Lo que yo y muchos otros desarrolladores de Windows no entendemos es por qué usted (como en la administración de WinDev) decidió que era una buena idea usar la fuerza bruta de C ++ / WinRT sobre nosotros con herramientas inferiores, incluso volver a MFC se siente mejor, al menos no lo estamos no copiar archivos manualmente.

En este momento me estoy enfocando en ASP.NET, WFP y Win32, solo sigo haciendo un seguimiento de las cosas de UWP con la esperanza de que Microsoft eventualmente se dé cuenta de que estamos hartos de reescribir aplicaciones y ser arrastrados por configuraciones manuales, como en UAP => UWP transición, .NET Framework a .NET Core, o sí C ++ / CX => C ++ / WinRT.

Esto es más una cuestión de retroalimentación, como miembro vocal de la comunidad de desarrolladores de Windows que se siente un poco decepcionado con las continuas reescrituras desde la introducción de Windows 8.

@pjmlp No estoy seguro de por qué está criticando C ++ / WinRT, que es solo una envoltura de C ++ (compatible con el estándar) alrededor de las API de Windows. Es posible escribir aplicaciones con C ++ / WinRT sin necesidad de herramientas (y archivos IDL, etc.).

@pjmlp No estoy seguro de por qué está criticando C ++ / WinRT, que es solo una envoltura de C ++ (compatible con el estándar) alrededor de las API de Windows. Es posible escribir aplicaciones con C ++ / WinRT sin necesidad de herramientas (y archivos IDL, etc.).

Ese es exactamente el problema, cero compatibilidad con herramientas frente a la experiencia de desarrollo de C ++ / CX en Visual Studio.

No hay soporte de edición para archivos IDL, ni siquiera resaltado de sintaxis, y mucho menos intelisense. ¡Y luego se le dice a uno que copie o combine manualmente las unidades de traducción generadas!

Esto es como hacer ATL en el pasado.

No me importa la compatibilidad con ISO C ++, UWP es de todos modos solo para Windows y no hay compiladores de C ++ sin extensiones de lenguaje.

No veo cómo alguien puede ver esto como un progreso, aparte de los chicos de WinDev que eran los únicos usuarios de WRL.

@pjmlp ,

No me importa la compatibilidad con ISO C ++, UWP es de todos modos solo para Windows y no hay compiladores de C ++ sin extensiones de lenguaje.

Para aquellos de nosotros que escribimos grandes aplicaciones multiplataforma de C ++, cumplir con los estándares es un gran problema. Las restricciones de C ++ / CX eran horribles (no hay variables miembro que no sean punteros en bruto, sombreros! ( ^ ), etc.). Actualmente tenemos una gran biblioteca de interoperabilidad C ++ / CLI, y los puntos débiles son demasiado numerosos para enumerarlos.

No hay soporte de edición para archivos IDL, ni siquiera resaltado de sintaxis, y mucho menos intelisense. ¡Y luego se le dice a uno que copie o combine manualmente las unidades de traducción generadas!

Nuevamente, está combinando C ++ / WinRT y herramientas. Son 2 cosas separadas. C ++ / WinRT es un contenedor de C ++ de las API de WinRT. IDL es para la generación de código, y sí, estoy de acuerdo en que es horrible, es tan malo que no lo uso.

Escribo una aplicación solo para Windows y todavía me importa el cumplimiento de los estándares, ya que me permite usar un compilador diferente en los casos en que MSVC falla.

@MarkIngramUK

Nuevamente, está combinando C ++ / WinRT y herramientas. Son 2 cosas separadas. C ++ / WinRT es un contenedor de C ++ de las API de WinRT. IDL es para la generación de código, y sí, estoy de acuerdo en que es horrible, es tan malo que no lo uso.

He estado codificando para plataformas Microsoft desde MS-DOS 3.3, agregué C ++ a mi caja de herramientas en 1992 con Turbo C ++ 1.0, he usado la mayoría de los productos de Borland y Microsoft en lo que concierne al desarrollo de C ++. No necesito ninguna conferencia sobre de qué se trata C ++ / WinRT.

Lo que definitivamente no es, es una coincidencia con la experiencia de desarrollador de C ++ Builder y Qt (con Qt Designer), que C ++ / CX mostró la promesa de alcanzar eventualmente, 25 años después.

Pero aparentemente la mayoría de la gente aquí solo quiere Visual C ++ 6.0 con ATL 3.0, y el resto de nosotros deberíamos seguir con la experiencia de escritorio .NET 5, WPF y Win32, porque somos una minoría que no es digna de consideración, de lo contrario, C ++ / WinRT nunca lo habría hecho. sido empujado de la manera que estaba.

Seamos honestos, C ++ / WinRT tiene ahora casi 4 años, y Microsoft ni siquiera pudo brindar soporte incluso para el resaltado de sintaxis e intelisense.

Algo que algunos de nosotros hemos creado en Notepad ++ (resaltado de sintaxis), ¿en serio?

Definitivamente muestra dónde están las prioridades, y no es así como WinUI ganará adopción, demasiadas reescrituras desde Windows 8.

@pjmlp , nuevamente estás hablando de cosas equivocadas. C ++ / WinRT es solo C ++, por lo que tiene resaltado de sintaxis y tiene soporte intellisense. Igual que cualquier otro código C ++ que tenga.

La integración de IDE podría ser mejor, como mencionó el resaltado de sintaxis IDL y cosas como sugerir crear una implementación predeterminada en .hpp y .cpp desde IDL (como cómo actualmente una función declarada sin una definición en un encabezado le solicita con garabatos verdes para crear uno), pero volver a C ++ / CX es una degradación neta de la OMI. Requeriría demasiado esfuerzo integrar todas las bibliotecas y el código compartido que uso con C ++ / CX, y obligarme a degradar mi proyecto de C ++ 20 a C ++ 17 (que no quiero renunciar, 20 me da demasiadas cosas buenas).

C ++ / WinRT también es mucho menos intrusivo que C ++ / CX cuando los programas solo quieren consumir clases de WinRT, no crearlas.

Qt y C ++ Builder logran su experiencia en C ++ en su mayoría compatible con los estándares (tenga en cuenta que Qt tiene algo similar a IDL, llamado Qt MOC). Si estos pueden, también VS. Solo requiere más amor de alguien en DevDiv.

Y como mencionaste anteriormente @sylveon , somos libres de construir con otros compiladores (actualmente construimos con MSVC y Clang / LLVM). Con C ++ / CX u otras extensiones de MS esto sería imposible.

@MarkIngramUK y @sylveon

Terminé con este hilo, está bastante claro que comentarios como el mío no son bienvenidos para mejorar la experiencia y las herramientas del desarrollador de WinUI.

Diviértase con su C ++ / WinRT compatible con el estándar.

¿Puedes editar esto para corregir el error tipográfico "no catering"? Creo que se supone que es "ahora ..."

@pjmlp Creo que entiendo EXACTAMENTE lo que quieres decir.

Hace aproximadamente un año abandoné la idea de migrar mi código UWP C ++ / CX a C ++ / WinRT. El incentivo para la migración fue poder usar Clang para compilar mi aplicación para UWP porque MSVC ++ contiene un error que informé hace unos 18 meses, pero simplemente no parecen estar interesados ​​en solucionarlo.

Sin embargo, resultó que Visual Studio no admite la creación de aplicaciones para UWP con Clang. Genial, entonces el beneficio de "ISO C ++ solamente" de C ++ / WinRT se fue por la ventana. Agregue a esto el hecho de que portar una base de código C ++ / CX sobre C ++ / WinRT es como viajar 20 años atrás en el tiempo.

Básicamente, he renunciado a portar nuestras aplicaciones de Android / iOS a Windows. Simplemente no es factible para una pequeña tienda como nosotros lidiar con el problema del desarrollo de aplicaciones de Windows además de desarrollar para Android / iOS.

@MarkIngramUK Parece que simplemente no entiende que las herramientas SON MUY IMPORTANTES. No todo el mundo tiene los recursos para compensar la falta de herramientas adecuadas.

Ahora, después de mi perorata, aquí está mi entrada:

Admite el uso de WinUI 3 con C ++ / CX. Una vez que las herramientas para C ++ / WinRT sean aceptables para las empresas que no tienen los recursos para construir sus propias herramientas, podría estar bien cambiar a C ++ / WinRT. Ahora definitivamente no lo es.

@pjmlp Creo que entiendo EXACTAMENTE lo que quieres decir.

Hace aproximadamente un año abandoné la idea de migrar mi código UWP C ++ / CX a C ++ / WinRT. El incentivo para la migración fue poder usar Clang para compilar mi aplicación para UWP porque MSVC ++ contiene un error que informé hace unos 18 meses, pero simplemente no parecen estar interesados ​​en solucionarlo.

Sin embargo, resultó que Visual Studio no admite la creación de aplicaciones para UWP con Clang. Genial, entonces el beneficio "ISO C ++ solamente" de C ++ / WinRT se fue por la ventana. Agregue a esto el hecho de que portar una base de código C ++ / CX sobre C ++ / WinRT es como viajar 20 años atrás en el tiempo.

Básicamente, he renunciado a portar nuestras aplicaciones de Android / iOS a Windows. Simplemente no es factible para una pequeña tienda como nosotros lidiar con el problema del desarrollo de aplicaciones de Windows además de desarrollar para Android / iOS.

@MarkIngramUK Parece que simplemente no entiende que las herramientas SON MUY IMPORTANTES. No todo el mundo tiene los recursos para compensar la falta de herramientas adecuadas.

Ahora, después de mi perorata, aquí está mi entrada:

Admite el uso de WinUI 3 con C ++ / CX. Una vez que las herramientas para C ++ / WinRT sean aceptables para las empresas que no tienen los recursos para construir sus propias herramientas, podría estar bien cambiar a C ++ / WinRT. Ahora definitivamente no lo es.

Por curiosidad, ¿cuál fue el error reportado hace 18 meses? ¿Tiene un enlace en alguna parte?

hola miguel
___editado para arreglar el terrible estado de las cosas después de responder desde Outlook para Android___

Tuve una idea que puede aclarar tus objetivos para las vistas previas y los lanzamientos, ya que dijiste que la plataforma Winrt es lo que estás usando para desarrollar WINUI.

tome este artículo, que menciona un montón si IDL escribe y copia manualmente archivos if y modifíquelo para que coincida con el estado en el que está trabajando en las herramientas

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

Si no es aquí, quizás podamos discutirlo en otro lugar.

por cierto, me has convencido sobre el diseñador XAML, especialmente con herramientas sobre la existencia como XAML Studio. (si solo pudiera cargar algún código detrás para poder cargar correctamente XAML que hace uso de IValueConverter ...

Como mencioné en mi publicación anterior, el cumplimiento estándar de C ++ 17 de C ++ / WinRT en sí mismo en la mayoría de los casos no es un incentivo para migrar una base de código C ++ / CX a C ++ / WinRT porque está obligado a compilar con el compilador Visual C ++ de Microsoft. de todas formas. Si pudieras cambiar el compilador, eso cambiaría por completo.

Pero Visual Studio no admite el cambio del compilador para componentes de Windows Runtime. Para mí es un misterio por qué esto no es compatible, especialmente porque es compatible con aplicaciones de escritorio como se describe en esta publicación de blog . El soporte de Clang realmente debería expandirse para los componentes de Windows Runtime.

Estamos usando Clang para compilar nuestra base de código para Android e iOS. Ser capaz de usar Clang para compilar nuestro código base para Windows sería en realidad una muy, muy buena razón para migrar desde C ++ / CX. La solicitud de función de Visual Studio para eso ya existe, pero el equipo de Visual Studio no ha hecho nada hasta ahora.

Tiene cumplimiento con el estándar C ++, tiene compatibilidad con Clang en Visual Studio para aplicaciones de escritorio. Por lo tanto, realice el paso final y proporcione una razón real para migrar desde C ++ / CX proporcionando compatibilidad con Clang para los componentes de Windows Runtime.

El cumplimiento de los estándares es útil para los consumidores, ya que menciona que los productores están apegados al MSVC. Hay una manera de "forzar" clang-cl (eso es efectivamente lo que ya hace el conjunto de herramientas LLVM ) estableciendo la propiedad CLToolExe en una ruta a clang-cl en el archivo .vcxproj . No estoy seguro de qué tan bien funciona en proyectos de UWP, pero vale la pena intentarlo.

Una vez que se desbloqueen las herramientas de producción de XAML y C ++ / WinRT en los proyectos de escritorio, también será un problema menor para mí.

@ackh Tengo un proyecto de UWP para construir bajo Clang 11:

Esto es lo que hice:

• Descargue el proyecto y agregue la siguiente directiva como la primera directiva en <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• Reemplazar <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> por <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Reemplazar <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> por <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Justo debajo de esto, agregue <ModuleOutputFile />
• Recargar el proyecto
• Construir

Sin embargo, tiene un par de trampas:

• Algunas advertencias con respecto a los argumentos no utilizados se apoyan: probablemente podría solucionarlos cambiando / eliminando los argumentos no utilizados.
• Por alguna razón, Clang emite un archivo de objeto de 64 bits en 32 bits, es posible que solo necesite agregar -m32 al CLI.
• Dado que Clang aún no implementa completamente las corrutinas, no podrá usarlas.
• VS realiza una reconstrucción completa de un solo subproceso cada vez que ejecuta la aplicación en lugar de incremental y / o paralelo.

Sugeriría abrir un problema en https://github.com/microsoft/ProjectReunion para llamar la atención sobre esto.

@sylveon Muchas gracias por publicar estas instrucciones. Lo intentaré en algún momento, pero aún espero que Visual Studio lo admita de fábrica en algún momento.