Runtime: Portar System.Xaml a .NET Core

¡HORRA! ¡Reconocimiento/reconocimiento oficial! Y sí, me doy cuenta de que esas palabras NO equivalen a "compromiso", pero esto es definitivamente mejor que todo lo que he visto hasta ahora. @terrajobst eres mi héroe. :corazon: :corazon: :corazon:

@cwensley y @SuperJMN , sería genial tener un diálogo entre todos aquí. Idealmente (desde mi perspectiva), todos deberían usar un puerto/versión de la nueva biblioteca Xaml y no tener diferentes versiones/dialectos de Xaml disponibles. ¿Es esto remotamente posible? Estoy de acuerdo con eso si no, pero me gustaría ver si podemos si es así. :)

Además, actualmente estoy en un "año sabático de trabajo (de clientes mandones LOL)" y tengo 3-4 meses programados para Xaml multiplataforma solo. Literalmente, podría trabajar a tiempo completo y ayudar en esto durante ese tiempo si fuera necesario. Cualquier cosa por la causa (y también, ¡soy un oportunista para el buen momento!)

Si System.Xaml es de código abierto, estoy seguro de que la comunidad puede transferirlo a .NET Core de acuerdo con los requisitos y objetivos de diseño de este proyecto, los mantenedores del proyecto solo tendrán que guiar a la comunidad. Aprovechemos el poder de la comunidad .net.

@ Michael-DST, estoy de acuerdo en que es importante tener un dialecto de xaml. Sin embargo, la implementación de eso podría ser completamente diferente. La estandarización en una sola implementación depende realmente de la comunidad.

Para Portable.Xaml , que es un puerto PCL 259/136 de la excelente implementación System.Xaml de Mono (licencia MIT), con muchas correcciones de errores. La idea es admitir todo lo que hace System.Xaml de MS (incluida la lectura/escritura) utilizando la misma API, pero no necesariamente limitarse a ella.

Como ejemplo de funcionalidad extendida, Portable.Xaml admite el uso de convertidores de tipo en los elementos de una lista, donde System.Xaml usa IList.Add(object) que tendría que implementar mediante una colección personalizada para admitir varios tipos.

@cwensley Reivindico mi ignorancia sobre esto... pero ¿cuál es la diferencia entre .NET Core y PCL? Pensé que eran iguales? Es decir, entendí que si diseñaba bajo un determinado perfil PCL, se trasladaría a .NET Core... esto fue hace un tiempo (y, sinceramente, estaba esperando .NET Core para RTM/W), así que ahora es un buen momento para refrescarse. :PAGS

Tengo entendido/impresión que Portable.Xaml es de hecho un puerto de System.Xaml de mono, mientras que OmniXaml es una reescritura desde cero que presenta un nuevo atractivo en el campo de análisis. Idealmente (desde mi propia perspectiva) sería genial fusionar los dos de alguna manera, pero ni siquiera estoy seguro de que sea factible o incluso deseable entre las dos bases. En mi mente (sin hacer la espeleología/análisis) básicamente está fusionando la madurez de uno (Portable.Xaml) con la nueva calidez del otro (OmniXaml).

@Michael-DST PCL 259 es compatible con .NET Core, según esta publicación . Ya he incluido \lib\dotnet como destino en el paquete nuget para Portable.Xaml, por lo que _debería_ poder usarse tal cual para .NET Core, aunque no lo he probado.

No he tenido tiempo de analizar OmniXaml, pero si de hecho es una reescritura desde cero, puede que no tenga sentido fusionar los dos proyectos, ya que estoy seguro de que las cosas se habrían hecho de manera completamente diferente. Tampoco estoy seguro del beneficio de tal cosa si Portable.Xaml está casi completo como está. Aunque podría estar equivocado (;

:) Sí, estoy explorando opciones aquí, y también lidiando con mi ignorancia de estar realmente en un mundo de código abierto. Odio la idea de tener múltiples bases de código haciendo lo mismo. Y especialmente dado que la comunidad Xaml es más pequeña, apestaría que se fragmentara desde el primer momento (¿no se supone que eso sucederá _después_ de que algo se vuelve demasiado exitoso por su propio bien?! Jaja). De todos modos, sería genial escuchar la opinión de @SuperJMN sobre esto. Sé que parecía bastante firme en sus nuevas modificaciones. Por ejemplo, el uso de MarkupExtensionContext en lugar de IServiceProvider para las extensiones de marcado, lo que sería un cambio importante para cualquiera que desee trasladar el código existente a este nuevo mundo.

Para aclarar, todos los perfiles PCL son compatibles con .NET Core. Los conjuntos de contratos y factorajes que tenemos ahora son una evolución de los perfiles PCL. Esto no se aplica a las bibliotecas portátiles de "estilo antiguo" (compiladas con mscorlib, etc.) que no son inmediatamente compatibles con .NET Core.

@Michael-DST

@terrajobst eres mi héroe. :corazon: :corazon: :corazon:

Si bien aprecio mucho su entusiasmo, quiero dejar en claro que cualquiera puede presentar solicitudes como esta. No necesita ningún patrocinio o reconocimiento de nuestra parte para presentar problemas, solicitar trabajo :-) Simplemente lo presenté yo mismo para ahorrar algo de tiempo y no ser demasiado patético ("siéntase libre de presentar un error") :-)

LOL @terrajobst está bien, mi entusiasmo es medio en broma y medio en serio... MSFT ha estado básicamente en silencio sobre este tema durante casi un año, a pesar de los numerosos votos y conversaciones extensas .

Entonces, considere lo que hizo como el equivalente a deslizar una comida debajo de la puerta de alguien encerrado en confinamiento solitario durante casi un año. :lengua_atrapada_fuera:

[Editar: después de leer esa analogía (y verla citada a continuación), debo decir que es terrible y probablemente influenciada por un artículo que estaba leyendo en ese momento: malditas noticias, ¿por qué deben influirme tanto?! Una mejor/relevante probablemente sería recibir una muy necesaria inyección de efectivo de una ronda ángel después de un año de funcionar con humo.]

cc: @Harikm86 , el propietario de System.Xaml

Me encanta XAML. Es un gran lenguaje declarativo para todo, desde Silverlight (sí, lo dije) hasta Windows Workflow y ahora para la nueva plataforma Universal App. La migración a Core hará posible la migración de otras tecnologías que dependen de XAML. ¡Necesitamos esto!

¡Qué bueno escuchar tu apoyo @rschiefer! Gracias por su aporte. Asegúrese de tener otros desarrolladores de Xaml que conozca que se unan a este hilo y ayuden con la conversación/dirección.

También soy un fanático de Silverlight y he estado persiguiendo su próxima encarnación desde 2011 (complemento desvergonzado: si desea que el equipo de Visual Studio sepa que le gustaría ver la próxima versión más inteligente de Silverlight, vote y hágales saber conocer aquí ).

Me gustaría tomarme un segundo y asegurarme de que cuando decimos "Xaml" deberíamos aspirar al conjunto de funciones/sistema Xaml que se encuentra en .NET 4.x+ (o "System.Xaml"). Incluso Xaml de Silverlight 5 servirá, de verdad.

(Por supuesto, también se desea agregar las nuevas mejoras que se encuentran en OmniXaml ).

Siempre que no sea la versión "nueva" bastarda de UWP que debe haber sido transferida por un equipo de internos, ya que todos hemos estado sufriendo desde entonces (ver los votos que menciono en mi publicación anterior).

Realmente incluso dudo en llamar a eso un sistema "Xaml", ya que en realidad es XML con un análisis de token adicional para la buena suerte (que claramente necesita). Dato curioso: el sistema Xaml de UWP finalmente usa el ensamblado System.Xaml durante su proceso de compilación. Mmm... #ironía.

Idealmente, una vez que este puerto esté en su lugar, el sistema UWP Xaml quedará obsoleto por completo y usará este en su lugar. Entonces podemos dejar atrás ese capítulo de la vergonzosa historia de Xaml, y los desarrolladores se regocijarán mucho.

Recuperar Silverlight en una forma más nueva y mejor tampoco sería malo. :) :) :)

@Michael-DST

Entonces, considere lo que hizo como el equivalente a deslizar una comida debajo de la puerta de alguien encerrado en confinamiento solitario durante casi un año. :lengua_atrapada_fuera:

Bastante justo :sonrisa:

@Michael-DST

De hecho, evité UWP hasta este punto sabiendo que muchas cosas habían cambiado y había olvidado que UWP usaba su propia "versión" de Xaml. Gracias por recordarme.

Estoy completamente de acuerdo, System.Xaml debe ser portado y luego podemos arreglar UWP para usar Xaml real.

Estoy completamente de acuerdo, System.Xaml debe ser portado y luego podemos arreglar UWP para usar Xaml real.

Lo siento @terrajobst , ahora tengo un nuevo héroe en @rschiefer. :sonríe sonríe Sonríe:

Gracias a todos por la discusión. Esto es genial para mí (¡pero podría impresionarme fácilmente!).

@Michael-DST @rschiefer

@helmsb ¡SÍ! jaja jaja!

FWIW, la popular tecnología Material Design de Google para web (Angular.js), aplicaciones (Android), etc., también está disponible en código abierto. Espero que este argumento ayude a convencer a los jefes y entidades similares a jefes.

@dsaf a qué te refieres?

FWIW He hecho referencia a este problema en un artículo publicado hoy titulado Is the Tide Turning on project.json? , una mirada a cómo Xaml es un mecanismo preferido para describir objetos .NET desde una perspectiva técnica y empresarial/IP de MSFT.

Bueno, todos, ¿qué tal ese trato de Xamarin, eh! algo me dice que este problema va a estar mucho más ocupado en los próximos meses. :sonreír:

No necesariamente. Puede haber una buena posibilidad de que veamos que Xaml de UWP o el sabor de Xamarin de Xamarin se conviertan en una biblioteca multiplataforma. Lo que podría significar que no puede ocurrir un puerto de System.Xaml o incluso una implementación de Xaml puramente administrada.

Sin embargo, el sistema Xaml de Xamarin es cerrado/interno y no es tan maduro como System.Xaml. El código en sí es bastante endeble (una preocupación reconocida por su parte; en realidad, usar eso es una de las razones por las que está cerrado/interno). Además, está estrechamente relacionado con BindingObject, lo que es prohibitivo si desea realizar una serialización POCO, etc.

Y como se describió anteriormente, el sistema Xaml de UWP es terrible. A menos que haya algo que tú sepas que yo no sepa. :lengua_atrapada_fuera:

¿Puede explicar qué quiere decir con "implementación de Xaml puramente administrada"? FWIW, mi expectativa aquí no es exactamente un puerto 1: 1 directo de System.Xaml, sino una biblioteca System.Xaml (¿Microsoft.Xaml?) "nueva" que toma todas las bondades de System.Xaml, Xamarin.Core.Xaml, y... bueno, diría Xaml de UWP, pero... :wink:

Escuché que internamente hay una preferencia por Xaml de UWP sobre WPF y Xaml, aunque obviamente diferentes equipos en Microsoft pueden tener opiniones diferentes. El Xaml de DotNet es, sin duda, más poderoso y flexible, pero como cualquier cosa con esos descriptores, es probable que tenga inconvenientes que son la razón por la que UWP se redujo tanto.
Y por no puramente administrado, me refiero a lo bueno de Xaml de UWP en el sentido de que no es exclusivo de DotNet. Entonces, un Microsoft.Xaml futuro potencial podría ser una implementación nativa multiplataforma con una fachada administrada para que pueda usarse fuera de DotNet. (Eso también excluiría su inclusión en dotnet/corefx a menos que se decidiera enviar esta biblioteca futura como un componente de CoreFX)

Está bien, estoy confundido. Cuando dices .NET... estás hablando de 4.6, ¿verdad? Según tengo entendido, esto es para una biblioteca .NET Core Xaml, que por su propia naturaleza es multiplataforma y exclusiva de .NET (4.6). Cuando dices "no es exclusivo de DotNet", ¿quieres decir "es DotNet inclusivo"? Doble negativo. :stuck_out_tongue: Obviamente, esto no es cierto porque no puede usar UWP Xaml en .NET 4.6 (ni le gustaría :stuck_out_tongue:).

Por favor, ilumíneme sobre lo que tengo mal aquí. Además, un buen objetivo aquí sería enviar Xaml como parte de CoreFX. Algunas discusiones han estado dando vueltas alrededor de esto por algún tiempo . -- y por supuesto, si no me equivoco @RichiCoder1 tienes tu voto para hacer exactamente esto en ese hilo... ¡Me preguntaba dónde había visto tu etiqueta antes! :sonreír:

Y también me gustaría decir que también escuché las inclinaciones internas hacia Xaml de UWP, pero eso fue antes de que hubiera una discusión comunitaria al respecto a partir de ese hilo más allá ( al estilo de la discusión de Twitter de Tim Heuer ). La aguja definitivamente se ha movido desde entonces. ¡Al menos, tenía mejor! JAJAJA. Hay quienes tienen la idea errónea de que "Xaml es para la interfaz de usuario" y luego está el resto de nosotros que entendemos cómo funciona. :lengua_atrapada_fuera:

Cuando digo DotNet, me refiero a DotNet, incluido el núcleo y el marco. Y me doy cuenta de que no puede usar UWP Xaml fuera de las aplicaciones UWP, me refería a la capacidad de usarlo en aplicaciones C++ UWP. Entonces, cuando digo que no sea exclusivo de DotNet, me refiero a estar a punto de usarlo desde C ++ (o potencialmente en otros idiomas). E imagino que la razón por la que el equipo propietario de XAML no considera seriamente los casos de uso fuera de la interfaz de usuario es porque es poco común o, en algunos casos, se difama activamente con Microsoft o con los socios. No es mi opinión personal, aprecio su expresividad y potencia.

Bien, genial @RichiCoder1 , gracias por tu explicación. Creo que _casi_ te sigo completamente ahora... cuando dices "marco" te refieres a 4.6?

En mi opinión, diré que parte de la razón por la que el equipo interno siente que es poco común usarlo fuera de la interfaz de usuario tiene que ver con la falta de compromiso con los desarrolladores, como creo que muestra la publicación de Tim. También soy culpable de esto, ya que realmente no me alegré de participar en MSFT hasta hace aproximadamente un año. De hecho, el Tweet de Tim se trataba de una votación que había realizado, después de haber estado quejándome personalmente o en privado con todos desde Windows 8.0 de que el sistema Xaml era completamente diferente y diferente de lo que debería ser. Cuando escuché rumores de que UWP (Windows 10) Xaml era básicamente el mismo, después de 3 años sin innovación ni mejora, fue cuando di un paso al frente. En retrospectiva, debería haber sido mucho antes.

Es seguro decir que fue una gran lección de aprendizaje. Ahora estoy (o al menos siento que lo estoy) mucho más integrado en el ecosistema y siento que me escuchan. De hecho, una votación _muy importante_ que hice hace poco más de cuatro meses fue marcada como En revisión por el prestigioso equipo de Visual Studio a principios de esta semana. Decir que mi mundo ha sido sacudido es quedarse corto. :sonreír:

Por marco, lo estoy usando para referirme al escritorio .Net. Esa parece ser la forma popular de diferenciar entre Core y Full Framework.

Estoy de acuerdo. Una de las cosas buenas de todos los movimientos recientes de Microsoft es que casi obliga a un mejor compromiso con los desarrolladores :).

Muy emocionado por eso yo mismo! Ahora solo para ver cómo funcionaría eso. Eso podría significar cualquier cosa, desde hacer que las herramientas de Xamarin sean de primera clase aparte de las aplicaciones UWP que usan sus proyectos compartidos, o podría significar algo de alto nivel, incluso eso. Solo el tiempo (y supongo, //Build) lo dirá.

Bien, genial... gracias por la información. :+1:

En cuanto a //construir... de hecho. :) Personalmente, me gustaría ver un modelo completamente nuevo que esté (¿vagamente?) basado en UWP y utilice la nueva bondad de Xamarin para moverlo a iOS/Droid. Un modelo Xaml más fuerte tampoco estaría de más. Supongo que deberíamos mantener este hilo en silencio hasta después del 28 de abril, después de todo. :lengua_atrapada_fuera:

¡Espero que ustedes puedan hacerlo! :)

Supongo que los muchachos de UWP adoptarían más fácilmente una implementación XAML que no extraiga el código .NET (incluso si ese código fuera material de .NET Core).

Como una caja negra autónoma (o solo dependiendo de UWP, pero no queremos eso ya que UWP no es multiplataforma [todavía] y si lo fuera, aún extrañaría una versión administrada que podría ejecutarse en .NET/ Silverlight [no puede bloquear sus aplicaciones solo para el destino Win10]).

Pero creo que esto es más o menos utópico, a menos que lo haga con una capa de abstracción y conectables/controladores para las diferentes aplicaciones de XAML (para UWP UI, para Workflow, para WPF/.NET, para Silverlight, etc.). Como DirectX parece una máquina a través de HAL (Capa de abstracción de hardware), que también abre la posibilidad de HEL (Capa de emulación de hardware; consulte las menciones en http://www.developer.com/net/asp/article.php/968461/What -es-DirectX.htm). Por supuesto, si no tiene cuidado, también podría abrir la puerta al infierno con respecto al rendimiento, pero dado que DirectX podría hacerlo, supongo que esa arquitectura no es mala.

+1 por migrar System.Xaml a .NET Core.
Espero ver un solo dialecto XAML unificado (.NET Xaml, UWP Xaml, Xamarin Xaml) en todas las plataformas en el futuro.
Se cree que es necesaria una versión .NET Core de System.Xaml para lograr esto.

+1

Para evitar alertas de notificaciones masivas, ahora tenemos una nueva forma de hacer +1 en los comentarios individuales en GitHub, para mostrar nuestro interés/reacción por el tema en cuestión:

Jaja @jasonwilliams200OK Por mi parte, no me importan las alertas de notificación masiva de los miembros de la comunidad que expresan su interés rudimentario en una solución System.Xaml poderosa y multiplataforma. :angel: Tal vez en otros temas compartiría tu dolor/molestia/frustración, sin embargo. :guiño:

Punto válido (y valioso), en cualquier caso. He agregado mi :+1: por la causa.

@jasonwilliams200OK

¡Gracias por llamar esto!

FWIW, acabo de invitar al equipo de Xamarin.Forms a unirse a la conversación aquí:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

O, en todo caso, hacer que todos _aquí_ estén al tanto de la conversación _allá_. :sonreír:

Tuve una gran discusión en los comentarios de esta publicación:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Básicamente, JSON vs Xaml para el nuevo sistema de proyectos que parece estar en marcha para Visual Studio (¡hurra!). Siéntete libre de unirte. :) Me alegro mucho de ver que esto tiene otro aspecto.

@Mike-EEE, también eche un vistazo a esta hoja de ruta: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. El nuevo sistema de proyectos impulsado por Roslyn va a ser... precioso.

whoa... loco que estoy escuchando acerca de esto ahora. esto debe ser a lo que se refería Scott Hunter en la publicación de blog antes mencionada con respecto a más información próximamente en una publicación futura. Es bueno verlo. El poder de Roslyn crece. Aunque, me sentiría más cómodo al ver algunos problemas para las definiciones de proyectos serializados en Xaml. :guiño:

Consulte el archivo Léame de ese repositorio: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (y el enlace al blog VS MSDN ), parece que podríamos reemplazar varios componentes mediante MEF, lo que permitiría insertar un serializador adicional para analizar la definición del proyecto escrita en XAML. Personalmente, he llegado a preferir JSON a XAML/XML cuando se trata de describir las propiedades y dependencias del proyecto, etc., ya que JSON es menos ruidoso (bueno, YAML es menos ruidoso que JSON y el estándar lang admite comentarios a diferencia de std-JSON, pero en dotnet world, YAML y otros lenguajes con sintaxis consciente de la sangría aún no han ganado terreno)

Personalmente, he llegado a preferir JSON a XAML/XML.

¡SEGURIDAD! QUITA A ESTE HOMBRE!!! Ejem, quiero decir... :)

Estoy a favor de tomar lo mejor de ambos mundos. @SuperJMN y @Grokys podrían hablar más sobre esto, pero creo que se están haciendo esfuerzos en OmniXaml para que sea menos detallado y hablador.

Mi problema con JSON no es con JSON en sí, sino con su enfoque de diseño, que también fue la base de la configuración de .NET (que supongo que fue su inspiración), y es decir, el esquema del objeto es "otro artefacto más" que el desarrollador tiene que administrar/mantener y _no_ la definición de clase. Es decir, en la programación Xaml (¡como saben!) la definición de clase _es_ el esquema del documento. Como resultado, esto le da una sensación muy natural al desarrollo del documento y también ayuda con las herramientas.

Sin mencionar la cordura del desarrollador. :smile: Nada me enfurece más que tener que buscar un documento de esquema oscuro y descubrir cómo instalarlo y hacer que funcione la inteligencia más simple.

El otro problema que tengo con JSON nuevamente no es específico de JSON, sino más bien de la mentalidad web y esa es la convención de nomenclatura. La configuración de .NET también sufrió esto. Es decir, podría estar definiendo un POCO como:

public class MyPoco {
    public string Property {get; set;}
}

Y su JSON (o app.config) se vería así (¡y puedes enseñarme esto si me equivoco!):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

Aquí nuevamente, Xaml está alineado entre la definición de clase y su contraparte serializada, por lo que lo prefiero.

Debo decir que la configuración de .NET fue la PEOR porque su diseño produjo cuatro artefactos para cada entidad de configuración:

1. El elemento en web/app.config
2. El archivo .xsd que tenía que vincular mágicamente de alguna manera a web/app.config (¡nunca conseguí que funcionara!)
3. Los elementos ConfigurationElement y/o ConfigurationSection que tomaron los valores de app/web.config (y mapearon el camelCase inconsistente a PascalCase -- ¡qué locura!)
4. El POCO que finalmente se conectó desde el elemento de configuración. (¡UF!)

No he estudiado el diseño del proyecto de JSON lo suficiente como para saber si hay un objeto POCO que se está serializando con el documento .JSON o si también se está produciendo la asignación extraña que se describe anteriormente. Me encantaría saber si sabes la respuesta a esto.

En cualquier caso, Xaml mejora este diseño al requerir solo dos artefactos:

1. El archivo de clase (.cs)
2. El archivo de datos (.xaml)

Finalmente, ¡gracias por ese enlace al archivo Léame! Soy una vez más "ese tipo" que no hace exactamente lo que pide el archivo. :risa:

si hay un objeto POCO que se está serializando con el documento .JSON o si también se está produciendo la asignación extraña que se describe anteriormente. Me encantaría saber si sabes la respuesta a esto.

Creo que si considera los atributos [DataContract] y [DataMember], entonces el marco .NET (en el nivel BCL) está ayudando a JSON y otros serializadores de datos. Sin embargo, no hay literales de objetos de JavaScript nativos/de bajo nivel <-> compatibilidad con la transición C# POCO por parte del compilador como JSON a JavaScript (y muchos otros idiomas) o CSON a CoffeeScript. Sin embargo, a diferencia de XML con todos sus vínculos XPATH XQUERY XSLT, JSON tiene el concepto de esquema para validar los datos y JSON.net lo admite como un campeón.

Para C#6 y superior, eche un vistazo a estos problemas/propuestas https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ dictionary , especialmente https://github.com/dotnet/roslyn/issues/6949 y siga los enlaces dentro. Con la nueva sintaxis del inicializador del diccionario C#6 y esta propuesta, parece que C# se está volviendo semánticamente más compatible con JSON.

Tengo que decir que la configuración de .NET fue la PEOR

De acuerdo, también puede disfrutar del patrón "Configuración" e "IOption" presentado por el equipo de ASP.NET como un paquete plug and play: https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , que reemplaza al antiguo y notorio administrador de configuración vinculado a XML.

JSON tiene el concepto de esquema para validar los datos y JSON.net lo admite como un campeón.

Suena como una definición de clase como esquema. :) :) :)

parece que C# se está volviendo semánticamente más compatible con JSON.

Jaja, bueno, para estar seguro, _cualquier_ objeto ya es compatible con JSON. JSON es excelente para hacer lo que se supone que debe hacer: anotar definiciones de objetos de una manera concisa y legible por humanos. Y no hay duda de que JSON.net hace un gran trabajo al cumplir este objetivo. Cuando comienzas a describir _aplicaciones_, comenzamos a entrar en el área donde esta conversación comienza a involucrarse, eh, a falta de una palabra mejor. :sonreír:

Al final, hay dos escenarios aquí (al menos para mí): describir objetos que deben transferirse entre los límites del servicio (ligero) y describir las aplicaciones que crean esos objetos (significativo). Personalmente, me gusta luchar por la coherencia en todas las formas posibles y minimizar el cambio de contexto. Mientras mantengamos nuestras opciones ( IOptions ? :risas:) abiertas y permitamos a los desarrolladores elegir el formato que tenga más sentido para ellos (¡y les permita usar las herramientas que los hagan sentir más eficientes! ) entonces todos ganamos aquí. :+1:

UWP XAML tiene menos funciones en comparación con el clásico .NET WPF XAML. Una de las características que más extraño son los TypeConverters.

Traté de crear mi propio TypeConverter como se sugiere aquí https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (el artículo es para WPF TypeConverters)

En UWP obtengo este "Tipo desconocido 'coche' en el espacio de nombres XML ' usando: App2TypeConverters '"

        <ListBox>
            <local:car></local:car>
        </ListBox>

¿Realmente no es posible agregar un TypeConverter personalizado en UWP? ¿O hay una solución alternativa? Leí en alguna parte que XamlCompiler está usando el IServiceProvider interno para registrar TypeConverter. Tal vez se puede registrar con él de alguna manera?
También me interesa obtener más información sobre los antecedentes relacionados con la compilación XAML. ¿Se seguirá generando XAML para BAML? ¿Podemos conectarnos de alguna manera a la compilación XAML?
Por lo tanto, abra System.Xaml.

Así que... ¿¿Esto significa que System.Xaml finalmente se unirá a la fiesta? :sonríe sonríe Sonríe:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-fasier-to-port-to-net-core/

Voy a conectarme aquí y decir:
a) Realmente me encantaría ejecutar XAML con .Net Core y
b) si , cuando eso suceda, tendría más sentido usar el tipo UWP, ya que ya se está transfiriendo a otras arquitecturas (por ejemplo, el empuje de IoT en Raspberry Pi).

Sin embargo, obtener WPF XAML sería increíble, si eso es posible.

De la misma manera que el núcleo de .NET se reconstruyó esencialmente desde cero, en función de la última década de aprendizaje, creo que se debe hacer lo mismo para XAML. La evolución WPF/Silverlight/WinRt-XAML ha sido una completa debacle. Un paso adelante, dos atrás (uno de lado). La promesa de XAML, Expression Blend, etc. nunca se ha hecho realidad.

El otro día escuché a Scott Hunter justificar que no hay una interfaz de usuario multiplataforma en Dotnet Core diciendo: "Bueno, nunca resultan buenos. En Windows, los usuarios esperan un botón con aspecto de Windows, en Mac, un botón de Mac". Bueno, lo siento, ¿dónde ha estado durante los últimos 5 años? La web domina por completo el diseño de la interfaz de usuario ahora y en la web no existe tal cosa como un "botón estándar", pero ¿adivina qué? Los usuarios han logrado resolverlo. Ese argumento simplemente se opone a toda evidencia. Estas interfaces de usuario web ahora dominan el comercio en el planeta. Pero aparentemente eso no es lo suficientemente bueno para Dotnet Core. ¿Por qué no podemos tener un XAML multiplataforma sin complacer ninguna aspiración [imaginaria] de "aspecto y sensación de plataforma estándar"?

Supongo que los principales obstáculos técnicos serían cómo interconectar "XAML" (o como se llame la plataforma de interfaz de usuario de próxima generación) con una API 3D multiplataforma, ya que obviamente no podemos depender de Direct3D/Direct2D en MacOS, etc. Pero supongo este problema ha sido resuelto por Unity, etc., que logran lograr ese objetivo.

Microsoft se ha demorado tanto en el tema de la fuente abierta de la familia de tecnologías XAML, que uno tiene que preguntarse si escondido dentro hay un caché secreto de bitcoins o las claves privadas de microsoft.com.

Continúe con MSFT: Open Source WPF/Silverlight/WinRT-XAML y deje que comience la próxima era dorada de UX.

Es bastante sorprendente escuchar lo que dices sobre Scott Hunter, @JackUkleja. ¿Tiene fuente / enlace para eso? Si lo que dice es cierto, además de lo que dice, esto muestra (sorprendentemente) ignorancia en varios frentes:

1. Esto es exactamente lo que Xamarin.Forms intentó abordar.
2. La experiencia de usuario, las interacciones y los estilos específicos de la plataforma (o que imitan, por así decirlo) son una preocupación que puede y debe abordarse mediante temas. Esto es en lo que WPF fue muy bueno (aunque en su punto podría y debería mejorarse).
3. Lo peor de todo es que esto no le da ninguna confianza al grupo de talentos que creó con éxito WPF, posiblemente el mejor marco de presentación de todos los tiempos. ¿Estás diciendo que ya no pueden resolver este problema? ¿O al menos hacer funcionar la misma magia que hizo que WPF tuviera tanto éxito de manera multiplataforma?

Una buena UX es una buena UX. Como bien apuntas, la web lo demuestra claramente. Los usuarios de aplicaciones nativas definitivamente están condicionados a una cierta apariencia para sus interfaces nativas, pero nuevamente, esto debería poder resolverse desde un tema.

Imagine poder ver una aplicación en un dispositivo iOS en un "skin" de Droid (completo con el comportamiento) y viceversa. Esto fue/es posible con WPF y es exactamente el tipo de pensamiento que debe llevarse a cabo en el futuro. Es decir, la apariencia/sensación/experiencia no debería interferir con el desarrollo y diseño de la aplicación. Debería poder aplicar un tema, y ​​whalah, "simplemente funciona". Desafortunadamente, esto fue/es un detractor para Xamarin.Forms en el sentido de que, si bien tiene en cuenta diferentes plataformas, hay mucha fricción involucrada para asegurarse de que todo funcione como se espera en cada plataforma de destino.

@ Mike-EEE Estoy bastante seguro de que Scott Hunter dijo palabras en ese sentido en este episodio de dotnet rocks: https://www.dotnetrocks.com/?show=1291

Re:

"el grupo de talentos que creó con éxito WPF, posiblemente el marco de presentación más grande de todos los tiempos"

...tengo entendido que una gran cantidad de los arquitectos originales, algunos de los involucrados con WPF dejaron MSFT y se fueron a Google y han estado involucrados con Angular. Están apareciendo muchas ideas de WPF en Angular y marcos relacionados, como las plantillas. Pero no importa de qué manera corte estos marcos web, creo que siempre tendrá el olor de HTML/CSS en el fondo. No todas las interfaces de usuario tienen sentido al estar basadas en documentos/semánticas y esa es la naturaleza de HTML, por lo que creo que el mundo aún podría hacer uso del "núcleo XAML".

[Jack... no creo que los datos sobre los arquitectos de Google y WPF sean correctos]

@rrelyea Eso fue lo que entendí, pero puedo estar equivocado. Sin embargo, podría haber jurado que leí que parte del equipo de WPF trabajó en Angular... ¿ Ian Ellison-Taylor, entre otros? (Aunque parece que ahora está de regreso en MSFT...)

olor a HTML/CSS en el fondo

Cuanta más conformidad y convergencia hacia los estándares HTML CSS unificados o cualquier tipo de estándares en ese sentido (C, C ++, JavaScript), mejor lugar sería este mundo. En su lugar, XAML con su característica única, puede presentarse como un marco superconjunto para la pila HTML+CSS, etc. o simplemente como un motor front-end alternativo para Razor de ASPNET: https://github.com/aspnet/Razor/issues/78 : bulbo:

@ jasonwilliams200OK FWIW/FYI ya existe un puerto "estándar" HTML/CSS de .NET en JSIL . Toda su salida es 100% compatible con HTML5 y se ejecuta en cualquier navegador moderno. Este es el tipo de pensamiento al que deberíamos aspirar, por supuesto (y debería haber sido el pensamiento desde la desaparición de Silverlight en 2011, pero estoy divagando).

Es decir, (hasta su punto, espero) lo ideal/preguntar es que los desarrolladores de .NET solo deberían tener que lidiar con .NET/C#/F#/VB.NET y nunca tener que tocar el CSS/HTML/JS, al igual que cómo Los desarrolladores de Xamarin .NET no tienen que tocar las bases de iOS/Droid (lo que sea que sean. :wink: ).

@Mike-EEE, en lenguajes de superconjunto (TypeScript a JavaScript o Less a CSS), podemos usar el código lang del subconjunto en superconjunto en el mismo archivo, pero no al revés. Entonces, el concepto de superconjunto va un poco más allá de cómo funcionan phonegap, cordova, etc. :)

Jaja, sí , @jasonwilliams200OK . Solo quiero asegurarme de que no terminemos haciendo un caso especial para nuestro enfoque/estrategia con la recuperación de .NET en el navegador. Tocar CSS/JS debe verse con el mismo desdén que tocar binario. :lengua_atrapada_fuera:

Como ejemplo, también hay otro proyecto Fayde que usa Xaml (yay), pero también depende de TypeScript (boo). Esta es la forma de NO hacerlo, ya que finalmente termina con dos bases de código incompatibles, una en TypeScript/JS para el código del cliente, .NET para todo lo demás, lo cual es muy costoso tanto en tiempo como en recursos.

motor frontal alternativo a Razor de ASPNET

Razor es solo un motor de plantillas en mi opinión. De hecho, en ese enlace que mencionó dice "... que puede elegir entre una larga lista de motores de plantillas de front-end para codificar".

Incluso escuché algunos comentarios de MS en contra de sintaxis especiales similares a C # como Razor dentro de la página HTML, a favor de los marcos que usan etiquetas personalizadas en su lugar.

por cierto, también existe Bridge.net (http://bridge.net) y otros compiladores de C# a Javascript que podrían combinarse con soluciones XAML como Fayde

Re XAML en HTML5/JS/etc. Hay un proyecto interesante Granular que está reimplementando WPF. Utiliza Saltarelle para compilar a JS. Un ejemplo en vivo está aquí .

Ese Granular es bastante fantástico, @ethanhs. Ese era uno del que no estaba al tanto. Dado que ha adoptado el mismo enfoque CSHTML5 , JSIL, Bridge.net (que menciona @birbilis ), sufre el mismo problema de no poder compartir código entre el servidor y el cliente mediante el uso de PCL, que es realmente el único viable manera de hacerlo en estos días.

Y realmente, tan bueno como se ve ese proyecto, resume bastante bien el paisaje infernal que los desarrolladores de .NET han tenido que soportar desde la desaparición de Silverlight. Él y una docena de otros hacen "un poco" el trabajo de hacer que .NET funcione en el navegador, pero no toda la experiencia que esperan aquellos con experiencia en Silverlight.

Todavía tiene que haber una solución unificadora única y solitaria que haga que los desarrolladores se olviden de Silverlight. Sin embargo, nos estamos acercando. Espero, al menos. WebAssembly parece prometedor pero no he visto/escuchado ningún desarrollo significativo desde hace un tiempo. El puerto/iniciativa impulsado por JSIL parece haberse ralentizado un poco y no ha tenido un registro desde octubre pasado.

Esperemos que tengamos un gran avance aquí en un futuro próximo. Me encantaría ver un anuncio hecho en la //construcción del próximo año que lo indique. :corazón: :+1:

Esa sería una de las mejores cosas que le han ocurrido a XAML en los últimos años.
¡Vota aquí !

Genial @bbougot. También hay otro voto, que _finalmente_ llamó la atención, después de casi 15 meses de existencia, sin contar los casi 3 años de no reconocer un terrible sistema Xaml para empezar (¡pero estoy divagando!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(En serio, ¿15 meses para siquiera reconocer un voto por el más obvio de los problemas? ¿Qué está haciendo el equipo de UWP allí? ¿Cuándo se hará cargo el equipo de Visual Studio o .NET y corregirá el barco? ¿Qué hará? .. ups, así es, estaba divagando...)

Además, no te olvides de votar este hilo. Le está yendo bastante bien @ 60 actualmente, especialmente considerando que este problema comenzó antes de que tuviéramos servicios tan sofisticados como GitHub Reactions. :sonreír:

¡Xaml es el único con el potencial de unificar todo el ecosistema de clientes!
Por favor, deshazte de DirectX, ¡abraza OpenGL!
¡UWP se ejecuta en la PC, en el teléfono, en el sitio web!
¡Viva Xaml!

Entonces, una pregunta civil aquí @terrajobst , @harikmenon y @karelz (veo que agregaron una etiqueta recientemente, así que felicitaciones, ¡los estoy involucrando en esto!). Por simple curiosidad, decidí aventurarme un poco y verificar el filtrado avanzado (o tal vez no) de GitHub en este repositorio. Pensando que había muchos votos y qué no para diferentes temas.

Aquí está la URL que estoy usando:
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Parece que este problema tiene 82 votos a favor actualmente y, si no me equivoco, el siguiente elemento más cercano en la lista está en 17. Eso hace que este problema sea, con diferencia, el más solicitado/votado en este repositorio, ¿correcto?

Si es así, tenía curiosidad por saber si esto tiene alguna relación con sus prioridades y/o planificación. Claramente, esto parece ser una pregunta/elemento _muy_ popular ahora (nuevamente, si entiendo correctamente), por lo que creo que tal vez sería bueno escuchar una actualización o un registro con respecto a la posibilidad de iniciar una conversación para progresar en hacer este problema una posibilidad.

Sería genial obtener cualquier perspectiva/contexto aquí, y/o si tengo algo completamente mal entendido con respecto a la demanda de los clientes. Sucede. 😄

Nuestros ingenieros de .NET Core están muy enfocados en .NET Standard 2.0 (también alta demanda de los clientes); consulte los detalles aquí y aquí . Veremos otras bibliotecas que no están en esa lista después de que tengamos .NET Core actualizado al estándar más reciente.

¡Gracias por señalar la consulta de votos a favor!

¡Gracias por tu respuesta @karelz! Muy apreciado. 👍

👼 👼 👼 Dejaré esto aquí mismo en caso de que alguien quiera darle me gusta/retuitear. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

He estado trabajando con xaml desde la versión 3 de .net, sentí la reducción de tamaño de Silverlight e incluso su muerte. Soy una persona que ama los cambios para mejorar para hacer las cosas mejores y más útiles. Pero ahora, con UWP, encuentro un retroceso en lugar de avanzar. No se preocupe por todas las características nuevas que, si se sienten, son geniales, pero carecen de la compatibilidad completa con xaml, como la aplicación de escritorio. Estuve tratando de crear una nueva aplicación en UWP, y aprendí por las malas que todo lo que aprendí ha cambiado nuevamente, no puedo encontrar mucho soporte en línea, como a dónde se ha movido la biblioteca xaml. Por ejemplo, el adorno que estaba debajo del marco ya no está, el x: static para las propiedades que no funcionan, debe buscar durante horas para encontrar un ejemplo o qué hacer. No hay ningún enlace para mostrar el del antiguo xaml al nuevo UWP...

@giworking ¡Es obvio que MS debería prestar atención al desarrollo del cliente! Como se cita a Satya Nadella, azule es el núcleo y el futuro de MS. La energía más fuerte para impulsar azule es todo el ecosistema .net. En comparación con Java, el lado del cliente es casi la única arma para persuadir a los codificadores y a las empresas para que adopten la nube de MS (en China, .net se encuentra realmente en una situación catastrófica, la gente habla de Java y reacciona "¿qué es f k s t xamarin?"). ....). Entonces, como codificador chino, cuando veo xamarin, uwp, typescript y cshtml5, sé que es posible unir todo el lado del cliente en el modo xaml+C#, pero ¿por qué nuestros amigos de MS no ven la oportunidad de obtener volver a la cuota de mercado chino con si?

¡Guau, este problema ahora tiene más de 100 votos a favor! Muchas gracias a todos los que han mostrado su apoyo. Si alguien está interesado, hay un artículo realmente ( ¡realmente! ) excelente de @terrajobst completo con su tremendo compromiso de desarrollador de marcas registradas en los comentarios aquí:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(En serio, todos los empleados de MSFT que publican una publicación de blog basada en la empresa deben seguir el ejemplo del Sr. Landwerth sobre cómo publicar y hacer un seguimiento de los inevitables, innumerables e innumerables comentarios que surgen después. Él es realmente el mejor con todo y parece como demasiados autores de MSFT, simplemente dejan que sus publicaciones se sequen y dejan las preguntas por muertas, ¡lo que por supuesto es una forma terrible de tratar a su audiencia!)

De todos modos, definitivamente vale la pena leerlo si aún no lo has hecho, especialmente los comentarios. Esto me lleva a por qué estoy publicando ahora como _estoy muy complacido de ver este problema mencionado en los comentarios junto con la pasión/deseo de llevar System.Xaml a la era de .NET Standard/multiplataforma_. 👍

154 votos a favor... y contando. 😎 El siguiente número más alto está en 25 , como referencia. #rueda chirriante

Esto debe hacerse. ¡Manos a la obra!

Tenemos una aplicación @ReactWindows dirigida a WPF en la que nos gustaría usar .NET Native para mejorar drásticamente la experiencia de descarga/instalación por primera vez para nuestras decenas de miles de usuarios de Windows 7. También tenemos planes futuros para llevar React Native a Linux y potencialmente reutilizar el código compartido de @ReactWindows pero apuntar a Xamarin.Forms.

Tener System.Xaml (y otras dependencias de tipo/método/ensamblado de WindowsBase, PresentationCore y Xamarin.Forms) disponible en NETCore vNext es fundamental para esta estrategia. Podemos solucionar esta deficiencia reescribiendo y redirigiendo los ensamblajes existentes, o completando los tipos/métodos faltantes en System.Xaml de Mono y construyéndolo para .NET Core, pero realmente preferiríamos que Microsoft intensificara y proporcionara lo que es necesario para la plataforma.. /cc @rozele @pre10der89

@matthargett Buena suerte en esto. Superé este problema hasta la saciedad cuando buscaba llevar el flujo de trabajo a .net core. Incluso llegó a ponerse en contacto con el equipo de xaml. No están ni remotamente interesados ​​en abrir System.Xaml. No entiendo por qué, ciertamente no hay nada que valga la pena proteger allí.

Puede ser que esto se considere después del lanzamiento de 2.0 a fines de abril.

Chicos, de nuevo, no necesitamos System.XAML para hacer que WF se transfiera a netstandard1.x ... Ya hay un buen trabajo de @dmetzgar en el que funciona el núcleo de WF. La pieza principal que falta es Transactions, que creo que regresará eventualmente en netstandard2.x .

La pauta principal del puerto de @dmetzgar es no tener ningún tipo de lenguaje de diseño vinculado al núcleo y tener primitivas básicas para que las personas puedan serializar el flujo de trabajo como quieran y luego crear diseñadores encima.

Por supuesto, este enfoque conducirá a una compatibilidad sin versiones anteriores con los flujos de trabajo actuales basados ​​en XAML, pero créanme, mover cualquier cosa a .Net Core ES un cambio importante, por lo que las personas deben comprenderlo.

Existe OminiSharp que podría aprovecharse para los diseñadores de XAML, pero nuevamente, el diseño/serialización está fuera del núcleo de WF. Debe ser delgado como todo lo demás con .Net Core.

Diría que este problema hizo en voz alta que la gente quiere mover WF a .Net Core, solo creo que quejarse con el equipo System.XAML para OSS, simplemente no está siendo productivo. El equipo de XAML tiene otras prioridades y es fundamental para el negocio de Windows/UWP/Xamarin, por lo que no espere que se ejecute OSS tan pronto. En lugar de eso, le pediría a @dmetzgar que haga público oficialmente el repositorio de WF bajo .Net Foundation, y guíe a la comunidad para ponerlo en funcionamiento sin establecer ningún cronograma o promesas sobre el lanzamiento de netstandard2.x . Sería un trabajo continuo impulsado por su equipo y ayudado principalmente por la comunidad que claramente quiere ayudar y salir adelante.

Mire lo rápido que evolucionan las cosas en el proyecto de Orleans... Fue una investigación de Microsoft que obtuvo OSSed el año pasado y es uno de los repositorios más grandes y activos en .Net Foundation y está impulsado principalmente por los esfuerzos de la comunidad (todavía tiene un equipo de MSFT trabajando a tiempo completo en él).

De todos modos, en mi humilde opinión, creo que debemos dejar de parlotear y comenzar a hacer algo. Está claro que el equipo de @dmetzgar no tiene ancho de banda para trabajar en eso, ya que su principal preocupación es admitir a los principales usuarios de WF, que son básicamente implementaciones grandes de Sharepoint que no tienen planes de llegar a .net core en absoluto. Por lo tanto, debe ser un esfuerzo impulsado por la comunidad (supervisado por el equipo de @dmetzgar ).

Chicos, de nuevo, no necesitamos System.XAML para hacer que WF se transfiera a netstandard1.x...

@galvesribeiro eso podría ser cierto, pero este problema es para que System.Xaml se traslade a .NET Core, del cual es, con mucho, la función más solicitada en el repositorio donde el equipo de .NET está solicitando comentarios. Si no escucha sus comentarios, ¿por qué solicitarlos? De todos modos, WF es simplemente _uno_ de los escenarios que satisfaría un puerto System.Xaml. Como sabe (¡o debería!) System.Xaml es capaz de mucho más.

El equipo de XAML tiene otras prioridades y es fundamental para el negocio de Windows/UWP/Xamarin, por lo que no espere que se ejecute OSS tan pronto.

Sí, ese es el problema aquí y lo que estamos pidiendo cambiar. :) Además, ni siquiera estoy seguro de que haya un "Equipo Xaml" en estos días, ¿verdad? Realmente se siente que esta tecnología se ha cerrado y estamos empezando a entenderla.

De todos modos, en mi humilde opinión, creo que debemos dejar de parlotear y comenzar a hacer algo.

100% de acuerdo. FWIW, @SuperJMN acaba de lanzar OmniXamlv2.0 , por lo que hay algunos esfuerzos de la comunidad en curso que se pueden aprovechar mientras MSFT prioriza sus energías y esfuerzos en torno a este problema (que, por cierto, se lleva a cabo durante aproximadamente 11 meses, y contando).

Hablando de eso, aquí hay un buen hilo sobre exactamente eso (es decir, la inactividad de MSFT en esto), con una cita de @terrajobst :

Para ser claros, no estoy diciendo que System.Xaml no pueda o no deba ser multiplataforma. Lo que digo es que System.Xaml no es muy útil fuera de WPF y WF, y NuGet es una métrica de proxy sensata para esa declaración. Por supuesto, System.Xaml podría tener sentido fuera del ámbito de la interfaz de usuario, pero ese es un paso secundario. Prefiero usar nuestros recursos AHORA MISMO para hacer que las piezas fundamentales funcionen bien y estén completas. Además, al tener una base convergente, la migración de componentes de nivel superior, como System.Xaml, también se vuelve mucho más fácil.

Así que no es una declaración de uno u otro; es una declaración de orden de ejecución.

Dejando a un lado la declaración muy incorrecta acerca de que System.Xaml no es útil fuera de WPF/WF, todo esto me suena a glish de gerente de proyecto, sin intención de abordar este problema. Mi objetivo no es ser crítico con esa declaración, ya que apoyo totalmente a Immo y el gran trabajo que hace aquí. Sin embargo, he dado vueltas lo suficiente como para permitir que ese tipo de lenguaje me dé una pausa y me ponga en una postura de esperar y ver (o más bien "créelo cuando lo vea" ¡LOL!) con respecto a este tema.

Mientras tanto, apoyo los esfuerzos actuales en .NET Standard 2.0 y espero con ansias lo que eso producirá. Tal vez podría ser mejor de lo esperado. Como mínimo, parece que podremos recuperar System.Xaml para proyectos de .NET Core que funcionen en plataformas Windows, lo cual es un buen comienzo para mí. 👍

@ Mike-EEE, en primer lugar, lo siento... Pensé que estaba respondiendo a esto https://github.com/dotnet/corefx/issues/2394 oO Esos dos problemas se correlacionaron tantas veces que me confundí.

En segundo lugar, no estoy diciendo que XAML solo sea útil para la interfaz de usuario. Lo usé durante tantos años en compilaciones TFS, WF en sí y últimamente para UI. Hay un montón de DSL como Azure ML y otros que podrían aprovechar XAML.

Lo que quise decir es que no veo que XAML se transfiera tan pronto a .Net Core. Como dijo Immo, primero deben hacerlo bien con las plataformas actuales. .Net Core ni siquiera tiene bibliotecas de manipulación de imágenes nativas todavía.

Hay varias implementaciones de XAML que van desde WPF con todas las funciones hasta aplicaciones débiles y sin muchas funciones en UWP. Debe ser unificado y estabilizado antes de que tal cosa tenga OSS. No hablo por los equipos que trabajan en ella. Simplemente creo que no haría nada diferente a ellos si tuviera que priorizar mis recursos.

Saludos a WF, lo siento de nuevo, pero mi comentario anterior estaba dirigido principalmente a aquellos que esperan que este problema sea la razón por la cual el puerto de WF al núcleo no está sucediendo tan rápido, lo cual no es cierto .

Esos dos problemas se correlacionaron tantas veces que me confundí.

Jaja @galvesribeiro No puedo decirte (o tengo miedo de admitirlo) cuántas veces eso también me ha mordido. No te preocupes por eso. ¡Por mi parte, aprecio la entrada independientemente!

FWIW, también parece que @cwensley continúa haciendo un gran trabajo con @ Portable.Xaml , ya que recientemente realizó mejoras de rendimiento en su adaptación mono de System.Xaml que la hace más rápida que la versión original. Casi parece que ese podría ser un buen punto de partida para un esfuerzo aquí, ya que probablemente sea lo más cercano a la experiencia System.Xaml original de todos los sabores/opciones que existen. Solo mis dos centavos inducidos por la cafeína para la mañana.

Porte System.Xaml a .NetCore

FWIW, más de 200 votos para este problema, ahora en 202. El siguiente problema más alto es dotnet/corefx#13526 en 47. Bueno, ERA 47... ahora es 48 después de mi voto. :) (Ve a mostrarle un poco de amor, es una buena idea.) #squeakywheel

Gracias por recordar @Mike-EEE ;-). Para establecer expectativas: todavía no estamos listos para comenzar a profundizar en él. Personalmente, espero que para marzo podamos comentar más sobre nuestros próximos pasos oficiales, incluso si es nuevamente "todavía no tenemos planes". (descargo de responsabilidad: estoy tratando de comunicar mi mejor suposición personal, ¡no lo tome como una promesa oficial del equipo!).

Cuando discutimos el tema un poco la última vez, la pregunta clave que surgió fue determinar cuáles de los más de 200 votos son realmente solo sobre System.Xaml vs. WPF. La suposición es que muchas personas no distinguen entre los dos. ¿Alguna sugerencia sobre la mejor manera de hacerlo? (por ejemplo, crear 2 problemas específicos y pedirle a la gente que vote por WPF frente a "Xaml puro, no WPF")

También sería útil tener una lista resumida de escenarios para System.Xaml con algunas estimaciones prioritarias (ahora están dispersas en una larga discusión). @Mike-EEE, ¿podría ayudarnos a armar algo, por favor? (ya que parece tener un gran interés y un profundo conocimiento en el área)

Definitivamente System.Xaml es lo que la gente quiere @karelz. Si alguien está pensando en WPF aquí, en mi humilde opinión, no es el lugar correcto. Hay un montón de otros marcos que aprovechan XAML como WF, TFS Build, etc. que todavía usan System.Xaml y eso nos ayudaría mucho.

@karelz Realmente aprecio tu respuesta aquí. Gracias por tomarse el tiempo para hacerlo. Como menciona @galvesribeiro , System.Xaml es más que una simple interfaz de usuario, lo que parece ser una comprensión clave que, lamentablemente, muchos MSFT pasan por alto. Es un poderoso paradigma de serialización que lo coloca por encima y más allá de cualquier otra solución de serialización, especialmente y particularmente cuando se trata de describir aplicaciones, que es lo que mejor hace (después de todo, la "A" en su apodo). Desafortunadamente, "aplicación" se ha combinado con "IU" y, por lo tanto, la fricción aquí.

Pasar por alto este aspecto fue una falla clave de UWP y es parte de la razón por la que a nadie le gusta trabajar con él. Por el contrario, Xamarin parece haber entendido este aspecto clave en su sabor de Xaml, pero es interno y no está expuesto como debería ser una oferta autorizada de primera clase (que es más o menos lo que busca este problema aquí).

TBH, el puerto de System.Xaml de @cwensley en Portable.Xaml parece ser el favorito en este momento. No solo ha portado System.Xaml de Mono (manteniendo su API familiar general), sino que ha agregado nuevas funciones y, de hecho, ha mejorado su rendimiento para que sea _mejor_ que el de System.Xaml.

En mi opinión, este problema podría ser tan simple como trabajar con @cwensley para hacer que lo que tiene en marcha sea la biblioteca autorizada de Xaml multiplataforma para usar en el futuro.

Fuera de esto, es donde se vuelve complicado y podría agregarse a su visión (comprensiblemente) complicada de este problema. Como System.Xaml proporciona un lenguaje expresivo y poderoso para describir aplicaciones (nuevamente, no solo las interfaces de usuario), también tiene un excelente soporte de herramientas integrado en Visual Studio (y, por supuesto, Blend). Así que, idealmente, sería increíble continuar con la misma gran experiencia y, de alguna manera, mantener la experiencia del diseñador de Xaml de forma multiplataforma, pero personalmente, eso es pedir una guinda al pastel de lo increíble que estamos discutiendo aquí. :)

Además, para reiterar aquí, la promesa (y la entrega) de Xaml también fue una mejora del flujo de trabajo de desarrollo entre el diseñador y el desarrollador. Me gusta pensar que, en última instancia, podemos dar un paso más y mejorar el proceso entre desarrollo y _devops_. Es decir, me encantaría ver un mundo en el que DevOps funcione en editores de configuración de aplicaciones bellamente diseñados (con tecnología Xaml) para administrar y mantener las aplicaciones implementadas.

_La idea general aquí es reducir el costo total en el desarrollo de aplicaciones desde la codificación hasta la implementación. Trabajar con editores y diseñadores bonitos es más barato (desde la perspectiva de los recursos) que tener que encontrar y contratar a alguien que tenga que meterse en el código (y/o scripts) para que la magia suceda._

Comparto esto con ustedes como una perspectiva de visión, solo para que estén conscientes. Sin embargo, no estoy seguro de cuán interesado está en escuchar esto. 😉 Entonces, si esto es simplemente un "¿qué se necesitaría para cerrar este problema y hacer que te vayas?" Sugeriría explorar la posibilidad de trabajar con el Sr. Wensley y ver si podemos aprovechar su gran trabajo hasta el momento (o si él está dispuesto a hacerlo). Si hay una manera de orientar esto para que pueda ser el paquete Xaml multiplataforma autorizado para el lanzamiento de .NET Core Wave 2 (¿alrededor de mayo?), entonces aún mejor. :)

Gracias por la información, definitivamente estoy interesado. También siento que mi(s) pregunta(s) anterior(es) no salieron como esperaba, así que permítanme señalar algunas cosas:

Sí, definitivamente estoy interesado en los detalles. ¡No creo que nadie esté disputando Xaml! = WPF en el lado de MSFT. Definitivamente no traté de hacer eso. Solo sé lo que no entiendo completamente, y estoy tratando de llenar los vacíos, es decir, comprender completamente la motivación y la necesidad de los escenarios de "Xaml puro".
(Por cierto: no entiendo muy bien su escenario devops y cómo Xaml es lo único/mejor para ayudar allí? ¿O cómo se usa realmente en el escenario?)

No estoy aquí para tratar de cerrar este tema. ¡Por favor! Eso ni siquiera se me pasó por la cabeza. Estoy aquí para ayudar a la comunidad a resumir la solicitud, de modo que pueda discutirse con las personas adecuadas (piense en los directores en este caso). Sí, parte de esto significa que yo (y/o un par de otros MSFT) tenemos que comprender completamente la solicitud para representarla más arriba, de ahí mis preguntas.

Lo admito, soy un buen ejemplo de una persona que no distinguió Xaml y WPF antes de ver este problema. De chats aleatorios con otros en el equipo de .NET, muchos saben que Xaml != WPF, pero no ven el "gran valor" de tener Xaml puro que se presenta aquí; por lo tanto, mis preguntas anteriores sobre los escenarios. Los escenarios me/nos ayudarán a comprender mejor la motivación y contar/vender mejor la historia. (Espero que no sea una sorpresa que cuando no hay una historia clara, nadie se siente ansioso por financiarla :) - la historia es un requisito previo para la financiación)
Así que pensemos en el discurso de ascensor para avanzar.

Con respecto al trabajo de @cwensley , es genial escuchar que puede haber algunas soluciones no tan costosas. Pero nuevamente, sería realmente útil comprender primero los antecedentes y POR QUÉ, antes de saltar a la solución. Espero que tenga sentido. (No estoy tratando de ser desdeñoso ni nada, solo repito que es más fácil hacer avanzar las cosas cuando se entiende y se acuerda el POR QUÉ)

@galvesribeiro Si alguien está pensando en WPF aquí no es el lugar correcto en mi humilde opinión

No comparto su confianza en que las más de 200 personas que votaron realmente entiendan el Xaml != WPF con tanto detalle. También supongo que al menos algunos lo miran: sí, obtengamos Xaml primero, entonces será más fácil solicitar WPF. Entonces, su escenario en mente todo el tiempo es WPF, mientras que "Xaml puro" es solo el primer paso hacia él.
Y tal vez me equivoque (aunque al menos no soy la única persona del equipo .NET con estas dudas)...
Otro ángulo podría ser desglosar "Xaml puro" en una lista de escenarios (WPF, desarrolladores anteriores, ¿tal vez un par de más?) y luego pedirles a las personas que voten por ellos. ¿Cuál de ellos realmente les importa a los que votaron aquí? ¿Qué es lo que realmente quieren?
(Esta no es una táctica de demora, ni nada malo, estoy tratando de entender al "cliente" aquí. Espero que tenga sentido; si tiene mejores sugerencias sobre cómo llegar a dichos datos, hable, estoy abierto a enfoques alternativos )

EDITAR: Como de costumbre, si cree que no estoy abordando el problema de la manera correcta, dígalo. Estoy tratando de hacer lo mejor que puedo aquí para ayudar, con las mejores intenciones. No sufro de la ilusión de saberlo todo, o de pensar que soy más inteligente que los demás.

@karelz Hay un montón de marcos de interfaz de usuario que están reinventando la rueda y escribiendo sus propios lenguajes de marcado solo porque XAML no es multiplataforma, incluso si no les gusta WPF en absoluto. Avalonia es uno de los mejores. Usan Omnisharp cuando podrían aprovechar XAML nativo en su lugar.

Workflow Foundation es un gran usuario/cliente de XAML y las personas en Port WF to .Net Core thread siempre preguntan al respecto.

Entonces, sí, estoy de acuerdo con usted en que debemos establecer las expectativas o dibujar un conjunto de características sin procesar sobre lo que se espera de la plataforma cruzada System.Xaml junto con los usos deseados como, por ejemplo, UI y WF.

@karelz

También supongo que al menos algunos lo miran: sí, obtengamos Xaml primero, entonces será más fácil solicitar WPF. Entonces, su escenario en mente todo el tiempo es WPF, mientras que "Xaml puro" es solo el primer paso hacia él.
Y tal vez me equivoque (aunque al menos no soy la única persona del equipo .NET con estas dudas)...

Entonces... ¿cuál es el problema con eso? Una solución multiplataforma similar a WPF podría ser algo bastante bueno. Xamarin no puede hacer GUI de escritorio multiplataforma.

@ jnm2 no está mal, pero si ese es el escenario principal (90%+), deberíamos planear hacer ambas cosas. Tener Xaml sin WPF no ayudará en tal caso (al menos no mucho). Y podría crear (potencialmente) una ilusión no válida de que WPF está comprometido y vendrá poco después.

Obtener WPF / GUI en .NET Core será un gran paso para .NET Core, que ahora se enfoca principalmente en escenarios de servidor y aplicaciones de consola.

@jnm2 tener System.Xaml ayudaría enormemente a las personas (como yo) que están _intentando_ llevar algo como WPF a otras plataformas (https://github.com/AvaloniaUI/Avalonia).

@grokys eso suena como un escenario razonable. ¿Puedes explicarlo un poco más? ¿Qué tan masiva sería la ayuda? ¿Qué es desafiante sin él?

También estoy usando Xaml para mi marco de interfaz de usuario de escritorio multiplataforma (no similar a WPF), Eto.Forms . Esta es la razón por la que creé el proyecto Portable.Xaml para comenzar, y hasta ahora ha funcionado bien para mí y para mis usuarios.

No me opongo a ayudar a que esta sea la implementación xaml multiplataforma "autoritaria" (como dice @Mike-EEE). Sin embargo, tenga en cuenta que solo trabajo en esto en mi tiempo libre (;

@karelz
No solo marcos de interfaz de usuario, se puede usar en muchas escenas como XAML a HTML

@Kation , ¿puedes compartir más detalles a qué te refieres exactamente?

Por cierto: comencé a resumir los escenarios en la publicación superior; si su escenario no está allí, descríbalo y una vez que lo entienda, lo agregaré allí.

@karelz
Con el potente editor XAML de Visual Studio, podemos crear rápidamente contenido de componentes personalizados.
Entonces, creo que podríamos usar XAML para generar contenido HTML en algún escenario especial, incluso más contenido SVG.
Este es un marco XAML a XML semiacabado para .Net 4.5. https://github.com/Kation/WebPresentation

No entiendo por qué quieres generar HTML o SVG desde XAML. ¿Cuál es el valor de XAML aquí?
¿El valor es que tiene un buen editor VS? También hay editores de HTML, ¿por qué no usarlos directamente?
¿O me estoy perdiendo el punto por completo?

@karelz
Porque quiero generar contenidos como WPF con plantilla y estilo en algunos proyectos.

@karelz gracias de nuevo por el diálogo. Yo por mi parte lo aprecio mucho.

No sufro de la ilusión de saberlo todo, o de pensar que soy más inteligente que los demás.

Oh, envidio. 😉

Entonces, su escenario en mente todo el tiempo es WPF, mientras que "Xaml puro" es solo el primer paso hacia él.

Sí, esta es de nuevo la combinación que mencioné. Xaml es un paradigma de serialización, puro y simple. Puede definir y describir una aplicación, y los componentes que la contienen, en ella. Para empezar, aquí hay un ejemplo de una _aplicación de consola_ descrita en Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Puede ver que hay comandos descritos en Xaml que brindan instrucciones sobre qué presentar al usuario mediante el uso de entradas y salidas de la consola. Esto no tiene nada que ver con WPF o "UI" (aunque técnicamente esta es la UI en el sentido de que la CLI es UI, pero espero que pueda notar la diferencia). Además, puede ver que uso extensiones de marcado y declaraciones de miembros estáticos directamente en el archivo. Esto es algo que no he visto en JSON ni en ningún otro formato de datos. Este es realmente el poder de Xaml, en mi opinión.

Como otro ejemplo de un escenario "Pure Xaml", aquí hay un archivo que propongo para un nuevo MSBuild independiente del formato:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(si sube un nivel, puede ver los otros formatos que hacen lo mismo, esta es la versión Xaml)

Este es el archivo del procesador que nuevamente es un conjunto de comandos ( System.Windows.Input.ICommand ) que describen los pasos a seguir en un proceso de construcción teórico. Nuevamente, no hay WPF ni UI, pero puede ver que emite mensajes a la consola.

Una característica que quiero señalar aquí que mencioné anteriormente es la herramienta integrada en Visual Studio que obtengo de este archivo:

Sin hacer ningún trabajo ni definir ningún esquema externo, Visual Studio simplemente "se enciende" y proporciona editores de propiedades completos con menús desplegables y otra interfaz de diseño basada en el esquema de clase del archivo con el que estoy trabajando (con suerte, esto facilitará el escenario de Devops comprender).

Además del archivo del procesador, aquí está el proyecto teórico o archivo de entrada que podría usarse para enviar al procesador:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Aquí trato de llegar al punto principal con _extensiones de marcado_ que se usan para proporcionar una versión (posiblemente de un archivo externo) y también para usar una consulta para proporcionar los archivos recopilados para construir (tenga en cuenta que tal vez no quiera hacer esto en un sistema de compilación final, pero quería demostrar su posibilidad).

Por cierto, este código de ejemplo es completamente operativo, por lo que debería poder obtener el SLN de ese repositorio y ejecutar la versión Xaml, los resultados deberían ser similares a los siguientes:

(Nota: funciona en Mi máquina , por lo que su kilometraje puede variar. 😄)

Por cierto: no entiendo muy bien su escenario de desarrollo y cómo Xaml es lo único/mejor para ayudar allí. ¿O cómo se usa realmente en el escenario?

Sí, debatí si entrar en eso, ya que sentí que mi publicación se estaba haciendo un poco larga. Con suerte, ahora el componente de diseño visual anterior puede ayudar a ilustrar lo que estoy jugando aquí.

Sepa y tenga en cuenta que, para mí, este es el juego final definitivo y por qué estoy tan entusiasmado con todo esto. _La razón es que termina reduciendo el costo total de propiedad de una aplicación durante su vida útil._

Entonces, en esencia aquí, de lo que estamos hablando aquí es del desarrollo basado en POCO, donde la edición y el diseño ocurren en los POCO utilizados dentro de un proceso de aplicación. Como sabemos, un desarrollador y diseñador trabajará en un archivo Xaml que describa los elementos POCO que se ocupan del dominio de la interfaz de usuario (aquí está el "WPF" tradicional de "Xaml", por así decirlo).

En mi mundo, me gustaría ver este proceso extendido para que el desarrollo entregue archivos Xaml para que los desarrolladores los usen para administrar/mantener aplicaciones que se han implementado en un entorno en vivo.

Puede pensar en esto como archivos de configuración en vivo. Habrá que resolver cómo se cargan, pero el resultado final sería algo como lo que ve en la captura de pantalla anterior en Visual Studio. En lugar de que el usuario final (devops) se vea obligado a poner sus manos en el código (o más bien, que una organización se vea obligada a contratar el costoso talento/conjunto de habilidades requerido como tal), trabajan con controles de edición visual limitados y validados para configurar y mantener la aplicación.

_La idea aquí es que, debido al esfuerzo (y la habilidad) que se requiere para hacer esto, en lugar de tener que conocer y comprender el código, el costo de mantener una aplicación después de la implementación se reduce considerablemente._

Un aspecto que no he mencionado sobre esto es que esos controles son realmente personalizables. Visual Studio tiene una API extensa (aunque obsoleta) para definir los editores visuales adjuntos a esas propiedades POCO:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

Todo esto está disponible ahora mismo en Visual Studio sin ningún trabajo, sobrecarga o esfuerzo adicional. Entonces, la idea final aquí sería crear un conjunto de editores y diseñadores poderosos para ayudar no solo en el proceso de desarrollo, sino también en el proceso de desarrollo.

Nuevamente, todo esto es visionario y sin ninguna base real en el mundo real (todavía). Sin duda, esta no es totalmente mi idea, sino que está inspirada en el grupo de patrones y prácticas con su Editor de configuración basado en Windows Forms . Simplemente llevé a este tonto un paso más allá y veo usarlo a través del poder de Xaml.

Por favor, hágamelo saber si tiene alguna pregunta adicional sobre este @karelz. Nuevamente agradezco el diálogo. No solo brinda la oportunidad de compartir, sino que también brinda la oportunidad de validar mis ideas y creencias. Y volviendo a la idea de saberlo todo (sí, soy culpable 👼), trato de mantener la mente abierta sobre las cosas y darme cuenta de que no tengo todas las respuestas. Este es definitivamente un proceso en el que estoy continuamente tratando de mejorar. ¡Gracias de nuevo!

@karelz : actualmente, Avalonia usa OmniXaml como su motor XAML y, aunque funciona bastante bien, todavía hay errores y funciones faltantes. Al igual que Portable.Xaml, OmniXaml es mantenido por un voluntario que no siempre tiene mucho tiempo para trabajar en él.

Si, de hecho, decide no abrir System.Xaml, tal vez la liberación de su conjunto de pruebas sería un buen compromiso, al menos de esa manera podríamos asegurarnos de que las implementaciones de terceros, como OmniXaml y Portable.Xaml, fueran lo más compatibles posible.

Creo que lo que necesita el ecosistema .net es un formato de serialización legible por humanos predeterminado, algo así como JSON en el mundo de Javascript. Este formato debe usar tipos de datos donet y usar directamente POCO como esquema. Luego, ese formato se puede usar para describir objetos POCO. Estas descripciones están tipeadas fuerte y estáticamente. Que puede ser un diseño de interfaz de usuario, configuración de aplicación en tiempo de ejecución, descripción de proyecto/flujo de trabajo o incluso para la comunicación entre dos programas .net. E incluso la comunicación con otros ecosistemas (como web/Javascript) también es posible, dado que implementan el formato. Pero debe diseñarse en torno al ecosistema .net. Es por eso que JSON/BOND/Protobuf/XML no es suficiente.

Históricamente, XAML de alguna manera cumplía con la responsabilidad. Ahora la pregunta es, qué tan bueno es para este papel. Si es lo suficientemente bueno, entonces creo que XAML debería convertirse en implementaciones netstandard y luego .net. Pero, si es posible, también se deben tener en cuenta otros formatos. Creo que la semana pasada salió http://www.ammyui.com/ . Un formato de descripción de la interfaz de usuario centrado en la simplicidad pero que se traduce en XAML. Porque XAML no era lo suficientemente simple. Yo mismo he propuesto un formato en roslyn repodotnet/roslyn#16648 basado en inicializadores (objeto, colección e índice). Y mi propuesta en realidad fue tomada de (y luego ligeramente modificada) esta publicación de blog de @bricelam del equipo de Entity Framework. Tanto su publicación como el hilo de mi propuesta tienen algunos ejemplos.

Mi punto es que debería haber un formato predeterminado para .net, ya sea XAML u otro.

@grokys Quería mencionar OmniXaml e invité a @SuperJMN a la conversación aquí, pero parece que nunca quiere participar. No estoy seguro de si es la configuración o qué (también he intentado en el gitter, ya que trabajas con él, tal vez puedas tener más suerte arrastrándolo aquí 😄). Por supuesto, OmniXaml también es definitivamente bienvenido a esta conversación.

@gulshan +💯 👏 👏! Jaja. Parte de la confusión de todo esto es que Xaml ES un formato y una tecnología MSFT. Con todas las inversiones y herramientas creadas a su alrededor, tanto con MSFT como en las empresas, es realmente incomprensible por qué parece haber una brecha para garantizar su continuidad, de modo que se puedan aprovechar los esfuerzos y las inversiones existentes.

Dicho esto, me gusta lo que veo con Ammy y sigo teniendo una mente abierta al respecto. O intentar tener uno. 👼

Creo que es importante reiterar por qué incluso nos molestamos con los archivos de datos para empezar, el valor principal en el uso de formatos de datos es:

• Agnóstico del lenguaje imperativo . El uso de los archivos no requiere que conozca un lenguaje de programación.
• Compatible con diseñadores/herramientas. _Usar un diseñador visual y/o habilitar una experiencia de diseñador visual con su producto conduce a un TCO más bajo _.

Dicho esto, lo que es personalmente importante para mí es:

• Flujo de trabajo integrado de desarrollador/diseñador
• Experiencia de diseñador visual para editar archivos a mano.
  
  
  
  • PropertyGrid (Ventana de propiedades) con API de editor extensible como se explicó anteriormente.
  
  
• extensiones de marcado
• Cereza en el pastel de asombroso: capacidad de aprovechar todo lo anterior dentro de escenarios fuera del desarrollo (ejemplo de DevOps anterior).

Si se cumplen todos estos, estaría dispuesto a considerar "otro formato .NET", pero obviamente preferiría mantener y extender Xaml como ese formato. Es una tecnología MSFT y, por lo tanto, propiedad intelectual, después de todo.

@ Mike-EEE Si un formato se puede deserializar a un POCO, todas esas características deberían estar funcionando. La ventana de propiedades en VS también aparece para escenarios que no son XAML. Pero una cosa que me preocupa es la legibilidad sin ningún soporte de editor. En algunos casos, debe editar un archivo de configuración en un servidor remoto y solo tiene vim. En comparación con JSON, XML (y XAML) no es tan bueno en este sentido, en mi humilde opinión.

Pero XAML tiene algunas cosas únicas (en realidad características que no son XML) como propiedades adjuntas, que son difíciles de imitar en un formato de serialización simple.

Primero votaría por WPF (para finalmente poder despedirme de xamarin.froms), luego por xaml

La ventana de propiedades en VS también aparece para escenarios que no son XAML

Correcto, pero no está casi "iluminado" como lo está para Xaml, con controles de edición totalmente personalizables, etc. Corrígeme si me equivoco aquí. No puede simplemente colocar el cursor en una propiedad en estos formatos y tener un menú desplegable para un campo de enumeración (por ejemplo). Esta experiencia es básicamente la próxima forma y versión de WinForms, lo cual es parte de la razón por la que es tan agradable (¡WinForms sigue siendo popular!).

En comparación con JSON, XML (y XAML) no es tan bueno en este sentido, en mi humilde opinión.

Sí, estoy de acuerdo, Xaml no es exactamente conciso y escuchará quejas sobre lo detallado que es. Aquí es donde OmniXaml está dejando su huella al proporcionar mejoras en torno al formato. También está compitiendo con otros formatos como TOML y YAML, entre otros.

características no XML) como propiedades adjuntas...

Y extensiones de marcado. 😄 Estas son características de su visión.

Lo que (creo) está jugando aquí @gulshan es esencialmente un "Data AST (árbol de sintaxis abstracta)". Si estamos hablando de mejorar seriamente Xaml (o formato de datos .NET), entonces este es el camino a seguir. Incluso podría ser impulsado por Roslyn. De hecho, tengo una voz de usuario que vota por esta misma idea (junto con una publicación de blog correspondiente ). Desafortunadamente no es muy popular ya que es un poco difícil de explicar, jaja. Esencialmente, tiene un árbol AST (datos) que se puede escribir en cualquier número de formatos. De esa manera, los desarrolladores (y las herramientas) pueden trabajar con él de acuerdo con el formato que tenga más sentido (estéticamente o no) para ellos.

para que finalmente pueda despedirme de xamarin.froms

De acuerdo contigo en ese aspecto @groege. 😎

@Mike-EEE No revisé previamente su propuesta de Data AST. Sí, es conceptualmente similar a la propuesta de serialización/notación de objetos predeterminada para .net. La idea es difícil de entender debido a su abstracción. 😄

Con respecto a XAML, un formato de serialización de datos fuertemente tipado basado en .net aliviará la necesidad de muchas extensiones de marcado XAML. Sin embargo, quedarán algunos que no pueden ser inicializados por alguna expresión (sin constructores). Desearía que algunas de estas capacidades de extensión de marcado fueran parte del mismo C#.

Bueno, no he tenido noticias de @karelz , así que solo puedo suponer que desde entonces ha estado sentado frente a su monitor al enterarse de que puede definir una aplicación de consola en Xaml:

Bromas (malas) aparte, por favor avíseme si tiene alguna pregunta adicional.

Además, de This Week in .NET, parece un motor bastante bueno que se está gestando en .NET Core . El primer comentario de este post lo dice todo . :)

@ Mike-EEE Sé que te debo una respuesta (está marcado como importante en mi bandeja de entrada y abierto en el navegador).
Hasta ahora, solo pude hojear las respuestas (¡muchas gracias a todos por todos los detalles e ideas!), pero no tuve tiempo de informarme sobre Xaml (como usted señala) y leer todas las respuestas a fondo para ser capaz de responder... lo siento, hay demasiados incendios y altos precios en este momento :(, lo abordaré más tarde, ¡lo prometo!

Todo bien @karelz! Aprecio mucho sus esfuerzos y diálogo aquí.

Aquí hay un voto para WPF de código abierto, cualquier otra versión de XAML es basura en comparación. Y en serio chicos, completen el ciclo en esto, tengan una TIENDA .net core/XAML para Unix y MacOS.

@ Mike-EEE lo siento mucho, todavía no tuve tiempo de volver a este problema :(

Oh hombre, no te preocupes por eso, @karelz , sé que todos están ocupados en este momento. Aprecio la conversación más que nada. Saqué mucho de mi cabeza. Es bueno verlo por ahí y reflexionar sobre ello como tal. Además, ya llevamos más de un año esperando esto hasta ahora... ¿qué son unos meses más o algo así? :)

deberían opensource silverlight 5... desde su movimiento html5, su win8 move/winrt... y ahora uwp y win10 y xamarin... ¡¡COMÚN!! patético estás perdido en la la land como hollywood o lo que sea...

¿Cómo se puede pasar de Silverlight 5 a toda esa basura? ¿CÓMO? ¿Cómo puede decir que respeta a sus usuarios cuando siempre rompe las interfaces de ensamblaje? Incluso cambia el nombre de su propio paquete Nuget y no proporciona una forma automática de pasar de los antiguos a los nuevos en Nuget. Es como si todavía usara a todos como infinitos. beta tester porque eres demasiado tonto para pensar con claridad antes de crear las ideas y codificarlas.

debe eliminar la necesidad de proyectos ios/android/uwp en formularios xamarin. PIENSE que hay formas mucho mejores de admitir multiplataforma que tener un proyecto para cada plataforma.

ahora trae todo bajo una f. framework you ass wipes (recomiendo la cobertura de wpf/silverlight y el lenguaje xaml, pero diablos, si quieres traer todo a xamarin, pero puedes agregar tipos de datos en el estilo/plantillas... extraña omisión como muchas y asegúrate de que tu f. nucrapget funcione A1 por una vez ... ¿por qué diablos necesitaría instalar un paquete nuget en todos los ensamblajes dependientes? Lo mismo con el dll al que se hace referencia ... ? no tienes visión ... niet ninguno ... capout ... todo este tiempo atrapado en ms basura .. podría haber creado mi propio f. sdks de clase mundial ..

No puedo pasar un día sin que la EM arroje una caca en mi camino... estoy considerando seriamente scala-js o simplemente swift... ¡es hora de salir de casa! Estoy harto

Bueno, les tomó casi dos años, pero UWP finalmente está especificando extensiones de marcado para su modelo Xaml:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

También cabe destacar que Noesis lanzó su producto v2.0 la semana pasada y se ve bastante impresionante. Su sistema Xaml ya cuenta con extensiones de marcado (en C++, con C# en camino), y no les llevó siete años llegar a la especificación. Ahora también es gratis para los desarrolladores independientes. Una vez que tenga en cuenta su compatibilidad con AmmyUI , debo decir que esto está en la parte superior de mi lista en lo que respecta a los modelos Xaml para cajeros automáticos:

http://www.noesisengine.com/

Hola , @karelz , tal vez puedas comentar sobre esto. Pero, ¿sabe si la "especificación" de UWP Xaml que está ocurriendo ahora tiene alguna correlación con este problema? Si no, ¿sabes si se puede? Una idea loca aquí, pero podría ser bueno resolver dos problemas por el precio de uno si se puede evitar. También dejé un mensaje allí sobre la votación de UWP, pero pensé que también haría ping aquí.

@Mike-EEE UWP Xaml "especificación" probablemente esté impulsada por otra organización (creo que en Windows); pedirles detalles sobre la voz del usuario es probablemente el mejor canal.

Sí, tenía miedo de eso. 😛 Recibí una respuesta allí, pero tengo que ser honesto, no tiene mucho sentido para mí.

Por lo que puedo asimilar, parece que van a seguir adoptando un enfoque de puertas cerradas con su proceso de especificación. Esto es preocupante, ya que parecería que conduciría a los mismos resultados que la última vez, terminando en una API que nadie quiere usar o adoptar.

Tal vez disfruten en secreto de que los desarrolladores se quejen de su trabajo. :)

En cualquier caso, si está leyendo esto y es un defensor de la colaboración y el desarrollo transparentes y de código abierto, y ha disfrutado de ser parte del éxito de la iniciativa de asp/.NET Core en este dominio, tómese un segundo para leerlo. a WPDev UserVoice y envíeles una nota animándolos a hacer lo mismo. El enlace se mencionó anteriormente, pero aquí está nuevamente para aquellos que están leyendo esto desde el correo electrónico:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Tengo que llamar a @birbilis y agradecerle su contribución anterior allí. Cualquier otra palabra amable de confianza que alguien pueda prestar para promover el proceso que todos usamos aquí sería muy apreciada. 👍

suspiro ... al igual que la voz del usuario, haces que la gente vote por cosas y, al final, incluso si fue popular, ¡no hagas nada al respecto!

Actualizar:
https://github.com/microsoft/xaml-estándar

Estoy seguro de que @Mike-EEE estará muy contento con esto ;P

Ese es un gran movimiento. Gracias por compartir @RichiCoder1

Desafortunadamente, es solo para la interfaz de usuario. Otros usos de XAML como Sharepoint y WF probablemente estén descartados.

Pero sí, al menos ayudará a estandarizar el XAML en todas las plataformas compatibles.

¡Buen movimiento!

Espero que lo dividan en capas.

Por ejemplo, aparte de la capa XAML base que no es UI, me gustaría ver la capa XAML 3D

@galvesribeiro Parece que alguien creó un problema: https://github.com/Microsoft/xaml-standard/issues/23 Le daría +1, no hay razón para que el estándar eventual no se divida.

Estoy seguro de que @Mike-EEE estará muy contento con esto ;P

¡Jaja y tienes razón, @RichiCoder1! Todo está mal y roto y en ninguna parte donde debería estar, pero es un comienzo. ;) Gracias por hacernos saber. 👍

Y muy complacido de ver a alguien creando https://github.com/Microsoft/xaml-standard/issues/23 para que yo no tenga que hacerlo. ;) ;) ;)

¡Por favor, considere incluir WF (Fundación de flujo de trabajo) en el estándar XAML!

@Suriman , por favor vote a favor!
https://github.com/Microsoft/xaml-standard/issues/23

Así que odio preguntar, y lo hago con el interés de ser un buen ciudadano de repos/emisión, pero ¿se necesita más esta cuestión? Quiero decir, ese repositorio ya está registrando más de 50 problemas que están entrando en MUCHO más detalles que este problema. ¡Parece que ya tiene vida propia!

¿Hay alguna razón para mantener este problema aquí abierto? A menos que esté malinterpretando algo (muy posible), creo que hemos logrado el objetivo aquí con Xaml Standard. Está impulsado por la comunidad y todo lo demás, lo que es más importante para mí, personalmente. :)

@ Mike-EEE Hay una diferencia sutil entre los dos problemas; me parece que uno se trata de estandarizar las API disponibles dentro de XAML (estrictamente en el mismo XAML), y el otro se trata de admitir XAML como un componente estándar de .NET similar a System.Xaml.

@lokitoth definitivamente está abierto a la conversación sobre esto, ya que todavía estoy tratando de asimilar todas las piezas nuevas. Supongo que es mejor comenzar sugiriendo ver el excelente e informativo video de @terrajobst que demuestra que el código "simplemente funciona" con el nuevo .NET Standard2.0. Personalmente, no he pensado en cómo afecta esto a System.Xaml. Pensé que debería "simplemente funcionar", pero tal vez estoy empezando a pensar que ahora estoy equivocado aquí (demasiado bueno para ser verdad).

Y para ser honesto, después de leer algunos de estos hilos en el repositorio de Xaml Standard, me estaba pateando por mi sugerencia anterior (☕️ ¡el café me obligó a hacerlo, lo juro! ☕️). Por lo que parece, "Xaml Standard" es mejor llamarlo "MSFT UX/UI Standard", ya que eso es lo que se trata principalmente en ese repositorio. Tal como está, Xaml como una poderosa tecnología de serialización no se presenta/muestra/destaca en absoluto (fuera de las pocas voces valientes aquí que se han esforzado allí), lo que también está generando cierta desconexión/confusión.

Personalmente, no he pensado en cómo afecta esto a System.Xaml.

Tendríamos que inspeccionar el ensamblaje para determinar si su árbol de dependencia se puede cargar en un contexto de .NET Standard 2.0. Si es .NET puro, es probable que funcione (aunque hay un conjunto completo de elementos en tiempo de compilación, por ejemplo, BAML, recursos integrados, etc., que se incorporarían a la cadena de herramientas de .NET Core)

Por lo que parece, "Xaml Standard" es mejor llamarlo "MSFT UX/UI Standard", ya que eso es lo que se trata principalmente en ese repositorio.

Eso, creo, es más una función de su anuncio en el contexto de UWP/Xamarin.Forms, lo que significa que los desarrolladores que se centran en esas dos plataformas, que pueden no haber estado expuestos a "BigXaml", son los que contribuyen principalmente. Aunque ve algunos problemas de "traer todo el dialecto WPF XAML" abiertos.

Dado que el equipo tiene que limpiar mucho, y que en este momento la tasa de problemas nuevos es bastante alta en relación con la cantidad de personas que contribuyen, le daría más tiempo para ver a dónde lo lleva el equipo.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
He creado un problema en Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

¡Gracias por avisarnos y contribuir a la conversación, @juepiezhongren!

bueno, @lokitoth , me alegro de que hayamos mantenido este problema intacto, ya que se decidió que https://github.com/Microsoft/xaml-standard/issues/23 no era apto para la luz del día.

Sin embargo, he creado un nuevo problema que creo que hace un mejor trabajo describiendo el problema en cuestión y sería increíble tener su voto positivo y/o contribuciones agregadas aquí: https://github.com/Microsoft/xaml-standard /temas/145

Para aclarar, lo que está buscando en realidad serían artefactos generados por _JavaScript_+HTML5+CSS3. TypeScript es en realidad un transpilador para JS. En lugar de hacer un transpiler de .NET para producir JS compatible con los estándares que se ejecutaría de manera efectiva en una navegación (como JSIL ), MSFT decidió dedicar el valioso tiempo del creador de C# para hacer algo que compitiera con él de manera efectiva y en última instancia.

Diría que no me hagan empezar con esto, pero creo que nunca me detuve. 😛

Además, otro punto es que CSHTML5 está muy cerca de lo que está buscando @weitzhandler , pero no permite el código compartido entre ensamblajes de cliente/servidor (como PCL, etc.). Así que aún termina con dos bases de código independientes e incompatibles para mantener, lo que resulta en el mismo problema de costo/negocio entre .NET y JS (o TypeScript 😉) que, digamos, no existe en una solución estrictamente de NodeJS.

¡Mi sueño es usar el estilo de escritura de la interfaz de usuario xml de Android para aplicaciones de escritorio con dot net core! ¡¡Sí, en serio!!

Cualquier esfuerzo para portar XAML a .NET core estoy dispuesto a ser voluntario.

En mis modificaciones a CoreWf (WorkflowFoundation en el estándar de red 2.0), veo que probablemente se requerirá System.Xaml o una implementación Portable.Xaml más compatible para permitir la carga de DynamicActivity desde Xaml . Tengo CoreWf ejecutándose en .NET Framework con la carga básica de DynamicActivity mediante System.Xaml, pero sigue fallando debido a un estado de análisis no válido en .NET Core con Portable.Xaml.

Una pregunta es ¿por qué el código de System.Xaml no se agrega al repositorio de fuente de referencia con licencia de Mit? ¿Hay alguna licencia, patente u otro problema? Si no hay problema, agregar este código a la fuente de referencia nos permitiría a nosotros, la comunidad, realizar la transferencia necesaria para admitir CoreWf. El repositorio de origen de referencia no compromete a Microsoft a admitir System.Xaml. ¿Debo agregar un problema que solicite que se abra System.Xaml?

Si System.Xaml no está abierto, ¿podemos tener un documento (que no sea la especificación Xaml) o soporte en forma de pruebas que describan los pasos correctos para analizar y tokenizar el código Xaml para WorkflowFoundation?

Hola FWIW @karelz , he puesto algunas ideas en el escenario de DevOps aquí:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Basado en algunos acontecimientos interesantes en Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Pensé en mencionarlo aquí, mientras estaba en eso. 👍 Además, este hilo está atrasado por un bache. 😆

@weitzhandler necesita actualizarse, ya que mono-wasm está en el camino alfa, es casi el momento de comenzar a olvidar js.

@weitzhandler Se requieren 2 o 3 años, pero no es solo una pila completa, es una pila universal para .net.

CoreRT también está a bordo: https://github.com/dotnet/corert/pull/4480 . Esperando un combo HTML+CSS+C# listo para producción el próximo año.

El paquete de compatibilidad de .net propuesto incluye System.Xaml con estado quizás y vinculado a este problema.

Aparentemente, este problema se ha vinculado para el paquete de compatibilidad 2.1. ¿Alguien puede confirmar? Veo que se ha etiquetado netfx-compat-pack, pero no con una versión. Sin embargo, tomaré eso por encima de todo lo que ha ocurrido hasta ahora. 😄

Odio decepcionar, pero creo que accidentalmente marqué esto como 2.1 cuando estaba actualizando a granel los problemas del paquete comapt. Me moví a Futuro para reflejar el estado quizás en la propuesta.

@ Mike-EEE parece que xamarin.wasm está por llegar.
https://github.com/mono/mono/pull/5924#issuecomment-343551464

Gracias por la actualización caballeros. Aprecio que pienses en mí. :) @terrajobst, eso es realmente decepcionante, pero agradezco que se haya tomado el tiempo para registrarse y actualizar. No estaba seguro de si todavía estabas suscrito a este hilo o no. 👼

Dado que nos estamos tomando el tiempo para conectar proyectos descaradamente (y que pasará algún tiempo antes de que obtengamos nuestra corrección oficial de Xaml), me tomaré un segundo para mencionar que pasé el año pasado ayudando con la versión 2 de ExtendedXmlSerializer , que fue lanzado recientemente. Cuenta con soporte experimental para extensiones de marcado y propiedades adjuntas (que funcionan en POCO, no se requiere DependencyObject ), y también serialización parametrizada estilo protobuf .

Si está buscando (o para agregar) la funcionalidad Xaml-ish mientras esperamos que llegue System.Xaml, no dude en comprobarlo, proporcionar comentarios o (mejor aún) enviar un PR en el repositorio. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft , ¿se admitirá Workflow Foundation xaml en proyectos SDK como parte de la iniciativa de escritorio 3.0?

@lokki No sé de planes. @terrajobst @karelz?

@danmosemsft
¿Por qué no hay un problema que diga "Proporcionar un marco de interfaz de usuario como parte de .NET Core"?

Este problema no habla específicamente sobre la falta de un marco de interfaz de usuario, y no parece que la gente aquí se dé cuenta de eso.
Vea esto: https://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler Este problema tiene MUCHO más sentido para mí ahora. Gracias por la aclaración.

Puedo ver que tener System.Xaml incluido en .NET Standard es útil, particularmente junto con XAML Standard.

si entiendo correctamente la "iniciativa de escritorio", debería poder usar las bibliotecas .NET que podía usar en el pasado, siempre que apunte solo a Windows (no estoy seguro de si su aplicación podrá adaptarse dinámicamente al entorno que se ejecuta, si la aplicación principal no puede hacerlo [por ejemplo, no se iniciaría si no encuentra, por ejemplo, el sistema operativo Windows], entonces probablemente podría hacerlo creando varios ensamblajes de .NET Core que llamen cosas específicas de la plataforma y cargarlos a pedido dependiendo de la plataforma en la que la aplicación detecte que se está ejecutando)

@birbilis no es suficiente. El mismo XAML tiene que representarse por igual en todas las plataformas.

La iniciativa de escritorio no se trata de XAML, se trata de que .NET Core no sea un silo de mínimo común denominador, sino que permita aplicaciones que puedan apuntar a plataformas específicas (o, idealmente, también se adapten dinámicamente a la plataforma en la que se ejecutan) y hacer que la aprovecharlos mejor, hacer integraciones específicas de la plataforma, etc. Se podrían crear API basadas en capacidades además de esta funcionalidad para que luego se puedan escribir aplicaciones que solo consulten la disponibilidad de una capacidad específica. Además, las API de abstracción/compatibilidad se pueden construir a partir de eso, conectando diferentes implementaciones para cada plataforma que los autores de una API estén interesados ​​en admitir.

Por ahora, creo que Portable.Xaml está muy cerca de System.Xaml ahora. Si encuentra algún problema, envíe sus comentarios.

El equipo de WPF (@dotnet/wpf-developers) acaba de anunciar el código abierto de WPF para .NET Core 3.0. Como parte de esto, las versiones preliminares de .NET Core 3.0 ahora contienen System.Xaml y las fuentes correspondientes están disponibles en https://www.github.com/dotnet/wpf.

por cierto