Runtime: Porta System.Xaml para .NET Core

HORA! Reconhecimento oficial/reconhecimento! E sim, eu percebo que essas palavras NÃO equivalem a "compromisso", mas isso é definitivamente melhor do que qualquer coisa que eu vi até agora. @terrajobst você é meu herói. :coração: :coração: :coração:

@cwensley e @SuperJMN , seria ótimo ter algum diálogo entre todos aqui. Idealmente (da minha perspectiva), todos deveriam usar uma porta/versão da nova biblioteca Xaml e não ter diferentes versões/dialetos de Xaml por aí. Isso é mesmo remotamente possível? Eu estou bem com isso se não, mas eu gostaria de ver se podemos, se sim. :)

Além disso, estou atualmente em um "trabalho sabático (de clientes mandões LOL)" e tenho 3-4 meses programados para Xaml multiplataforma sozinho. Eu poderia literalmente trabalhar em tempo integral e ajudar nisso durante esse tempo, se necessário. Qualquer coisa pela causa (e também, sou um oportunista do bom momento!)

se o System.Xaml tiver código aberto, tenho certeza de que a comunidade pode portá-lo para o .net core de acordo com os requisitos e objetivos de design deste projeto, os mantenedores do projeto precisarão apenas orientar a comunidade. Vamos aproveitar o poder da comunidade .net.

@Michael-DST, concordo que é importante ter um dialeto de xaml. No entanto, a implementação disso pode ser totalmente diferente. A padronização em uma única implementação depende realmente da comunidade.

Para Portable.Xaml que é uma porta PCL 259/136 da excelente implementação System.Xaml do Mono (licenciada MIT), com muitas correções de bugs. A idéia é suportar tudo o que o System.Xaml da MS faz (incluindo leitura/escrita) usando a mesma API, mas não necessariamente se limitando a ela.

Como exemplo de funcionalidade estendida, Portable.Xaml oferece suporte ao uso de conversores de tipo em itens em uma lista, onde System.Xaml usa IList.Add(object) que você precisa implementar usando uma coleção personalizada para oferecer suporte a vários tipos.

@cwensley Eu afirmo minha ignorância sobre isso... mas qual é a diferença entre .NET Core e PCL? Eu pensei que eles eram iguais? Ou seja, eu entendi que, se você projetasse sob um determinado perfil PCL, ele seria transferido para o .NET Core... isso foi há um tempo (e honestamente eu estava esperando o .NET Core para RTM/W), então agora é um bom momento para atualizar. :P

É meu entendimento/impressão que Portable.Xaml é de fato uma porta de mono do System.Xaml, enquanto OmniXaml é uma reescrita do zero que apresenta algumas novidades na arena de análise. Idealmente (da minha própria perspectiva), seria ótimo mesclar os dois de alguma forma, mas nem tenho certeza de que seja viável, ou mesmo desejável, entre as duas bases. Na minha opinião (sem fazer o spelunking/análise) é basicamente fundir a maturidade de um (Portable.Xaml) com o novo hotness do outro (OmniXaml).

@Michael-DST PCL 259 é realmente compatível com .NET Core, de acordo com este post . Já incluí \lib\dotnet como um destino no pacote nuget para Portable.Xaml, portanto _deve_ ser utilizável como está para .NET Core, embora não o tenha testado.

Eu não tive tempo de olhar para OmniXaml, mas se é realmente uma reescrita do zero, pode não fazer sentido mesclar os dois projetos, pois tenho certeza de que as coisas teriam sido feitas completamente diferentes. Também não tenho certeza do benefício de tal coisa se Portable.Xaml estiver quase completo como está. Mas posso estar errado (;

:) Sim, estou explorando opções aqui, e também lidando com minha ignorância em realmente estar em um mundo de código aberto. Eu odeio a ideia de ter várias bases de código por aí fazendo a mesma coisa. E especialmente com a comunidade Xaml sendo menor, seria uma droga fragmentá-la logo no início (isso não deveria acontecer _depois_ que algo se tornasse muito bem-sucedido para seu próprio bem?! haha). De qualquer forma, seria ótimo ouvir a opinião do @SuperJMN sobre isso. Eu sei que ele parecia bem firme em suas novas modificações. Por exemplo, o uso de MarkupExtensionContext no lugar de IServiceProvider para extensões de marcação, o que seria uma mudança importante para quem deseja portar o código existente para este novo mundo.

Para esclarecer, todos os perfis PCL são compatíveis com o .NET Core. Os conjuntos de contratos e factorings que temos agora são uma evolução dos perfis PCL. Isso não se aplica a bibliotecas portáteis "antigas" (compiladas em mscorlib, etc.) que não são imediatamente compatíveis com o .NET Core.

@Michael-DST

@terrajobst você é meu herói. :coração: :coração: :coração:

Embora eu aprecie muito seu entusiasmo, quero deixar claro que qualquer pessoa pode enviar solicitações como essa. Você não precisa de nenhum patrocínio ou reconhecimento nosso para arquivar problemas, pedindo trabalho :-) Eu apenas arquivei para economizar algum tempo e não ser super coxo ("sinta-se à vontade para registrar um bug") :-)

LOL @terrajobst está tudo bem, meu entusiasmo é meio irônico e meio sério... MSFT está basicamente em silêncio sobre esse assunto há quase um ano, apesar de numerosos votos e conversas extensas .

Então, considere o que você fez o equivalente a deslizar uma refeição sob a porta de alguém trancado em confinamento solitário por quase um ano. :stuck_out_tongue:

[Edit: depois de ler essa analogia (e vê-la citada abaixo), devo dizer que é terrível e provavelmente influenciado por um artigo que eu estava lendo na época - maldita notícia, por que você deve me influenciar tanto?! Um melhor/relevante provavelmente estaria recebendo uma injeção de dinheiro muito necessária de uma rodada de anjo depois de um ano de fumaça.]

cc: @Harikm86 , o proprietário do System.Xaml

Eu amo XAML. É uma ótima linguagem declarativa para tudo, desde o Silverlight (sim, eu disse isso) ao Windows Workflow e agora à nova plataforma Universal App. A portabilidade para o Core possibilitará portar outras tecnologias que dependem do XAML. Nós precisamos disso!

Muito bom ouvir seu apoio @rschiefer! Obrigdo por sua contribuição. Certifique-se de que outros desenvolvedores Xaml que você conhece participem deste tópico e ajudem com a conversa/direção.

Eu também sou um fã do Silverlight e tenho perseguido sua próxima encarnação desde 2011 (plug sem vergonha: se você gostaria de informar a equipe do Visual Studio que gostaria de ver a próxima forma mais inteligente do Silverlight, vote e deixe-os conheça aqui ).

Eu gostaria de tomar um segundo e ter certeza de que quando dizemos "Xaml" devemos aspirar pelo sistema/conjunto de recursos Xaml encontrado no .NET 4.x+ (ou "System.Xaml"). Até o Xaml do Silverlight 5 serve, na verdade.

(É claro que também é desejável adicionar as novas melhorias encontradas no OmniXaml .)

Desde que não seja a "nova" versão bastardizada da UWP que deve ter sido portada por uma equipe de estagiários, pois todos nós sofremos com isso desde então (veja os votos que mencionei no meu post acima).

Eu realmente hesito em chamar isso de sistema "Xaml", pois é realmente XML com alguma análise extra de token para dar sorte (o que claramente precisa). Curiosidade: o sistema Xaml da UWP usa o assembly System.Xaml durante o processo de compilação. Hum... #ironia.

Idealmente, quando essa porta estiver em vigor, o sistema UWP Xaml será totalmente descontinuado e usará esta. Podemos, então, deixar para trás aquele capítulo embaraçoso da história do Xaml, e teremos muito regozijo do desenvolvedor.

Recuperar o Silverlight em uma forma mais nova e melhor também não seria ruim. :) :) :)

@Michael-DST

Então, considere o que você fez o equivalente a deslizar uma refeição sob a porta de alguém trancado em confinamento solitário por quase um ano. :stuck_out_tongue:

Justo :smile:

@Michael-DST

Na verdade, evitei o UWP até este ponto, sabendo que muita coisa havia mudado e tinha esquecido que o UWP usava sua própria "versão" do Xaml. Obrigado por me lembrar.

Eu concordo completamente, System.Xaml deve ser portado e então podemos corrigir UWP para usar Xaml real.

Eu concordo completamente, System.Xaml deve ser portado e então podemos corrigir UWP para usar Xaml real.

Desculpe @terrajobst , eu tenho um novo herói agora em @rschiefer. :sorriso: :sorriso: :sorriso:

Obrigado a todos pela discussão. Isso é super legal para mim (mas eu poderia ficar facilmente impressionado!).

@Michael-DST @rschiefer

@helmsb SIM! LOL haha!

FWIW, a popular tecnologia de design de materiais do Google para web (Angular.js), aplicativos (Android) etc. também está disponível em código aberto. Espero que este argumento ajude a convencer os chefes e entidades semelhantes a chefes.

@dsaf o que você quer dizer?

FWIW Fiz referência a esse problema em um artigo publicado hoje intitulado Is the Tide Turning on project.json? , veja como o Xaml é um mecanismo preferencial para descrever objetos .NET de uma perspectiva técnica e de negócios/IP da MSFT.

Bem pessoal, que tal aquele negócio do Xamarin, hein! algo me diz que esta questão vai ficar muito mais movimentada nos próximos meses. :sorrir:

Não necessariamente. Pode haver uma boa chance de vermos o Xaml do UWP ou o sabor do Xaml do Xamarin se tornar uma biblioteca de plataforma cruzada. O que pode significar que nem uma porta de System.Xaml ou mesmo uma implementação de Xaml puramente gerenciada pode acontecer.

O sistema Xaml do Xamarin é fechado/interno e nem de longe tão maduro quanto o System.Xaml. O código em si é bastante frágil (uma preocupação reconhecida do lado deles - na verdade, usar isso é uma das razões pelas quais é fechado/interno). Além disso, é fortemente acoplado a BindingObject, o que é proibitivo se você deseja fazer serialização POCO, etc.

E, conforme descrito acima, o sistema Xaml da UWP é terrível. A menos que haja algo que você saiba que eu não saiba. :stuck_out_tongue:

Você pode explicar o que quer dizer com "implementação Xaml puramente gerenciada"? FWIW, minha expectativa aqui não é exatamente uma porta 1:1 direta do System.Xaml, mas uma "nova" biblioteca System.Xaml (Microsoft.Xaml?) que leva toda a bondade do System.Xaml, Xamarin.Core.Xaml, e... bem, eu diria Xaml da UWP, mas... :wink:

Ouvi dizer que internamente há uma preferência pelo Xaml da UWP sobre o WPF e tal Xaml, embora obviamente equipes diferentes na Microsoft possam ter opiniões diferentes. O Xaml do DotNet é sem dúvida mais poderoso e flexível, mas como com qualquer coisa com esses descritores que provavelmente vem com desvantagens que são a razão pela qual a UWP é tão reduzida.
E por não puramente gerenciado, estou me referindo à única coisa legal sobre o Xaml da UWP, pois não é exclusivo do DotNet. Portanto, um futuro Microsoft.Xaml em potencial poderia ser uma implementação nativa multiplataforma com uma fachada gerenciada para que pudesse ser usada fora do DotNet. (Isso também excluiria sua inclusão no dotnet/corefx, a menos que esta futura biblioteca fosse decidida como um componente do CoreFX)

Tudo bem, estou confuso. Quando você diz .NET... você está falando 4.6, certo? Do meu entendimento, isso é para uma biblioteca .NET Core Xaml, que por sua própria natureza é multiplataforma e exclusiva do .NET (4.6)? Quando você diz "não é exclusivo DotNet" você quer dizer "é DotNet inclusivo"? Duplo-negativos. :stuck_out_tongue: Isso obviamente não é verdade porque você não pode usar UWP Xaml no .NET 4.6 (nem você gostaria de :stuck_out_tongue:).

Por favor, me esclareça sobre o que eu tenho de errado aqui. Além disso, um bom objetivo aqui seria enviar o Xaml como parte do CoreFX. Alguma discussão tem circulado sobre isso há algum tempo . -- e com certeza, se não estou enganado @RichiCoder1 você tem seu voto para fazer exatamente isso nesse tópico... Eu queria saber onde eu vi sua tag antes! :sorrir:

E eu também gostaria de dizer que também ouvi as inclinações internas em relação ao Xaml da UWP, mas isso foi antes de haver alguma discussão da comunidade em torno dele começando nesse tópico acima e além ( ala Tim Heuer's Twitter discussão ). A agulha definitivamente se moveu desde então. Pelo menos, era melhor! LOL. Há aqueles com o equívoco de que "Xaml é para interface do usuário" e há o resto de nós que entende como funciona. :stuck_out_tongue:

Quando digo DotNet, quero dizer DotNet incluindo núcleo e estrutura. E percebo que você não pode usar UWP Xaml fora de aplicativos UWP, eu estava me referindo à capacidade de usá-lo em aplicativos C++ UWP. Então, quando digo que não é exclusivo do DotNet, quero dizer estar prestes a usá-lo em C++ (ou potencialmente em outras linguagens). E imagino que a razão pela qual a equipe proprietária do XAML não considera seriamente os casos de uso fora da interface do usuário é porque é incomum ou, em alguns casos, ativamente difamado pela Microsoft ou por parceiros. Não é minha opinião pessoal, aprecio sua expressividade e poder.

OK grande @RichiCoder1 obrigado pela sua explicação. Eu acho que _quase_ te sigo completamente agora... quando você diz "framework" você quer dizer 4.6?

Na minha opinião, direi que parte do motivo pelo qual a equipe interna sente que é incomum usá-lo fora da interface do usuário tem a ver com o baixo envolvimento com os desenvolvedores, como acho que a postagem de Tim mostra. Eu também sou culpado disso, pois eu realmente não fiquei animado por envolver o MSFT até cerca de um ano atrás? Na verdade, o Tweet de Tim foi sobre um voto que eu fiz, depois de reclamar pessoalmente/particularmente para todos desde o Windows 8.0 que o sistema Xaml era completamente diferente e diferente do que deveria ser. Quando ouvi rumores de que o UWP (Windows 10) Xaml era basicamente o mesmo - após 3 anos sem inovação ou melhoria - foi quando eu intensifiquei. Em retrospectiva, deveria ter sido muito mais cedo.

É seguro dizer que foi uma grande lição de aprendizado. Estou (ou pelo menos sinto que estou) agora muito mais integrado ao ecossistema e sinto que estou sendo ouvido. Na verdade, um voto _muito importante_ que fiz há pouco mais de quatro meses foi marcado como Em Revisão pela prestigiosa equipe do Visual Studio no início desta semana. Dizer que meu mundo foi abalado é um eufemismo. :sorrir:

Por framework, estou usando para me referir ao desktop .Net. Essa parece ser a maneira popular de diferenciar entre Core e Full Framework.

Eu concordo. Uma das coisas boas sobre todos os movimentos recentes da Microsoft é que quase força um melhor envolvimento com os desenvolvedores :).

Muito animado sobre isso mesmo! Agora só para ver como isso funciona. Isso pode significar qualquer coisa, desde tornar as ferramentas Xamarin de primeira classe, além de aplicativos UWP usando seus projetos compartilhados, ou pode significar algo de alto nível, até mesmo isso. Só o tempo (e eu acho, //Build) dirá.

OK legal... obrigado pela informação. :+1:

Quanto a // construir... de fato. :) Pessoalmente, eu gostaria de ver um novo modelo completamente que é (vagamente?) baseado em UWP e utilizar a nova bondade Xamarin para movê-lo para iOS/Droid. O modelo Xaml mais forte também não faria mal. Acho que devemos manter este tópico quieto até depois de 28 de abril, afinal. :stuck_out_tongue:

Espero que vocês consigam! :)

Acho que os caras da UWP adotariam mais facilmente uma implementação XAML que não extrai código .NET (mesmo que esse código fosse material .NET Core).

Como uma caixa preta independente (ou apenas dependendo da UWP, mas não queremos isso, já que a UWP não é multiplataforma [ainda] e, se fosse, ainda perderia uma versão gerenciada dela que pudesse ser executada em .NET/ Silverlight [não pode bloquear seus aplicativos apenas para o destino Win10]).

Mas isso é mais ou menos utópico eu acho, a menos que você faça isso com uma camada de abstração e pluggables/drivers para as diferentes aplicações de XAML (para UWP UI, para Workflow, para WPF/.NET, para Silverlight etc.). Assim como o DirectX parece uma máquina via HAL (Hardware Abstraction Layer), que também abre a possibilidade de HEL (Hardware Emulation Layer - veja menções em http://www.developer.com/net/asp/article.php/968461/What -is-DirectX.htm). Claro que se você não tomar cuidado, isso também pode abrir a porta para o inferno em relação ao desempenho, mas como o DirectX pode puxá-lo, acho que essa arquitetura não é ruim

+1 para portar System.Xaml para .NET Core.
Espero ver um único dialeto XAML unificado (.NET Xaml, UWP Xaml, Xamarin Xaml) sendo usado em todas as plataformas no futuro.
Ele acha que uma versão .NET Core do System.Xaml é necessária para conseguir isso.

+1

Para evitar alertas de notificação em massa, agora temos uma nova maneira de marcar com +1 os comentários individuais no GitHub, para mostrar nosso interesse/reação pelo tópico em questão:

Haha @jasonwilliams200OK Eu, pelo menos, não me importo com alertas de notificação em massa de membros da comunidade expressando seu interesse rudimentar em uma solução System.Xaml poderosa e multiplataforma. :angel: Talvez outros tópicos eu compartilharia sua dor/aborrecimento/frustração, no entanto. :piscadela:

Ponto válido (e valioso), em qualquer caso. Eu adicionei meu :+1: pela causa.

@jasonwilliams200OK

Obrigado por chamar isso!

FWIW, acabei de convidar a equipe do Xamarin.Forms para participar da conversa aqui:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Ou se qualquer coisa, faça todos _aqui_ cientes da conversa _ali. :sorrir:

Tem uma ótima discussão acontecendo nos comentários deste post:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Basicamente JSON vs Xaml para o novo sistema de projeto que parece estar em andamento para o Visual Studio (hooray!). Sinta-se à vontade para participar. :) Estou tão feliz em ver que isso está recebendo outro olhar.

@Mike-EEE, também dê uma olhada neste roteiro: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. O novo sistema de projeto movido a Roslyn será... precioso.

uau... louco que eu estou apenas ouvindo sobre isso agora. isso deve ser o que Scott Hunter estava se referindo na postagem do blog acima mencionada em relação a mais informações em uma postagem futura. Bom ver. O poder de Roslyn cresce. Embora, eu me sinta mais confortável vendo alguns problemas para definições de projeto serializado Xaml. :piscadela:

Veja o readme desse repositório: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (e o link para o blog VS MSDN ), parece que poderíamos substituir vários componentes usando MEF, o que possibilitaria inserir um serializador adicional para analisar a definição do projeto escrita em XAML. Pessoalmente, passei a preferir JSON sobre XAML/XML quando se trata de descrever as propriedades e dependências do projeto etc., pois JSON é menos barulhento (bem, YAML é menos barulhento que JSON e o padrão lang suporta comentários ao contrário de std-JSON, mas no mundo dotnet, YAML e outros langs com sintaxe com reconhecimento de recuo ainda não ganharam força)

Pessoalmente, passei a preferir JSON sobre XAML/XML

SEGURANÇA! REMOVA ESSE HOMEM!!! Aham, quero dizer... :)

Sou a favor de tirar o melhor dos dois mundos. @SuperJMN e @Grokys podem falar mais sobre isso, mas acredito que esforços estão sendo feitos no OmniXaml para torná-lo menos verboso e conversador.

Meu problema com JSON não é com JSON em si, mas sua abordagem de design que também foi a base da configuração do .NET (que suponho que foi sua inspiração), ou seja, o esquema do objeto é "mais um artefato" que o desenvolvedor tem que gerenciar/manter e _não_ a definição de classe. Ou seja, na programação Xaml (como você sabe!), a definição de classe _é_ o esquema do documento. Como resultado, isso dá uma sensação muito natural ao desenvolvimento do documento e também ajuda/ajuda com as ferramentas.

Sem mencionar a sanidade do desenvolvedor. :smile: Nada me enfurece mais do que ter que perseguir algum documento de esquema obscuro e descobrir como instalá-lo e fazer com que o intellisense mais simples funcione.

O outro problema que tenho com o JSON novamente não é específico do JSON, mas mais da mentalidade da Web e isso é a convenção de nomenclatura. A configuração do .NET também sofreu com isso. Ou seja, você pode estar definindo um POCO como:

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

E seu JSON (ou app.config) seria algo como (e você pode me ensinar sobre isso se eu estiver errado!):

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

Aqui, novamente, o Xaml está alinhado entre a definição de classe e sua contraparte serializada, e é por isso que eu o prefiro.

Eu tenho que dizer que a configuração .NET foi a PIOR porque seu design rendeu quatro artefatos para cada entidade de configuração:

1. O elemento em web/app.config
2. O arquivo .xsd que você precisou vincular magicamente ao web/app.config (nunca consegui fazer isso funcionar!)
3. Os elementos ConfigurationElement e/ou ConfigurationSection que pegaram os valores de app/web.config (e mapearam o camelCase inconsistente para PascalCase -- ah, que loucura!)
4. O POCO que finalmente foi conectado a partir do elemento de configuração. (Ufa!)

Não estudei o design do projeto JSON o suficiente para saber se há um objeto POCO que está sendo serializado com o documento .JSON ou se o mapeamento estranho descrito acima também está ocorrendo. Eu adoraria saber se você sabe a resposta para isso.

De qualquer forma, o Xaml aprimora esse design exigindo apenas dois artefatos:

1. O arquivo de classe (.cs)
2. O arquivo de dados (.xaml)

Finalmente, obrigado por esse link para o readme! Eu sou mais uma vez "aquele cara" que não faz exatamente o que aquele arquivo pede. :risonho:

se houver um objeto POCO que está sendo serializado com o documento .JSON ou se o mapeamento estranho descrito acima também estiver ocorrendo. Eu adoraria saber se você sabe a resposta para isso.

Acho que se você considerar os atributos [DataContract] e [DataMember], então o framework .NET (no nível BCL) está ajudando JSON e outros serrailizers de dados. No entanto, não há literais de objeto JavaScript nativo/de baixo nível <-> Suporte de transição C# POCO pelo compilador como JSON para JavaScript (e muitas outras linguagens) ou CSON para CoffeeScript. No entanto, ao contrário do XML com todos os seus laços XPATH XQUERY XSLT, o JSON tem o conceito de esquema para validar os dados e o JSON.net o suporta como um campeão.

Para C#6 e acima, dê uma olhada nestes problemas/propostas https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ dicionário , especialmente https://github.com/dotnet/roslyn/issues/6949 e siga os links dentro. Com a nova sintaxe do inicializador de dicionário C#6 e essas propostas, parece que o C# está se tornando semanticamente mais amigável ao JSON.

Eu tenho que dizer que a configuração .NET foi a PIOR

Concordo, você também pode desfrutar do padrão "Configuration" e "IOption" introduzido pela equipe ASP.NET como um pacote plug and play: https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , que substitui o antigo gerenciador de configuração vinculado a XML.

O JSON tem o conceito de esquema para validar os dados e o JSON.net o suporta como um campeão.

Parece uma definição de classe como esquema. :) :) :)

parece que o C# está se tornando semanticamente mais amigável ao JSON.

Haha bem, para ter certeza, _any_ objeto já é compatível com JSON. O JSON é ótimo para fazer o que se destina a fazer: anotar definições de objetos de maneira concisa e legível por humanos. E não há dúvida de que o JSON.net faz um ótimo trabalho para atingir esse objetivo. Quando você começa a descrever _aplicativos_, então começamos a entrar na área em que essa conversa começa a se envolver, por falta de uma palavra melhor. :sorrir:

No final, existem dois cenários aqui (pelo menos para mim): descrever objetos que devem ser transferidos entre limites de serviço (leves) e descrever os aplicativos que criam esses objetos (significativos). Pessoalmente, gosto de lutar pela consistência de todas as maneiras possíveis e minimizar a troca de contexto. Contanto que mantenhamos nossas opções ( IOptions ? :laughing:) abertas e permitamos que os desenvolvedores escolham o formato que faz mais sentido para eles (e permite que eles usem as ferramentas que os fazem sentir mais eficientes! ) então todos nós ganhamos aqui. :+1:

UWP XAML tem menos recursos em comparação com o clássico .NET WPF XAML. Um dos recursos que mais sinto falta são os TypeConverters.

Tentei criar meu próprio TypeConverter conforme sugerido aqui https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (o artigo é para WPF TypeConverters)

Na UWP eu recebo com este “Tipo desconhecido 'carro' no namespace XML ' usando: App2TypeConverters '”

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

Não é realmente possível adicionar um TypeConverter personalizado no UWP? Ou existe uma solução alternativa? Li em algum lugar que o XamlCompiler está usando o IServiceProvider interno para registrar o TypeConverter. Talvez possa ser registrado com ele de alguma forma?
Também estou interessado em aprender mais sobre os antecedentes da compilação XAML. O XAML ainda será gerado para BAML? Podemos de alguma forma nos conectar à compilação XAML?
Então, por favor, abra System.Xaml.

Sooooooo... isso significa que o System.Xaml finalmente vai se juntar à festa??? :sorriso: :sorriso: :sorriso:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

Eu vou entrar aqui e dizer:
a) Eu realmente adoraria executar XAML com .Net Core e
b) se quando isso acontecer, faria mais sentido usar o sabor UWP, pois já está sendo portado para outras arquiteturas (por exemplo, o push IoT no Raspberry Pi).

No entanto, obter o WPF XAML seria incrível, se isso for possível.

Da mesma forma que o .NET Core foi essencialmente reconstruído do zero, com base na última década de aprendizado, acho que o mesmo deve ser feito para o XAML. A evolução WPF/Silverlight/WinRt-XAML foi um desastre completo. Um passo para frente, dois para trás (um de lado). A promessa de XAML, Expression Blend etc nunca se concretizou.

Eu ouvi Scott Hunter justificando nenhuma interface do usuário multiplataforma no Dotnet Core outro dia dizendo "Bem, eles nunca ficam bons. No Windows, os usuários esperam um botão com aparência do Windows, no Mac um botão do Mac". Bem, me desculpe - onde ele esteve nos últimos 5 anos?? A web domina inteiramente o design da interface do usuário agora e na web não existe um "botão padrão" - mas adivinhe? Os usuários conseguiram resolver isso. Esse argumento simplesmente se opõe a todas as evidências. Essas UIs da Web agora dominam o comércio no planeta. Mas aparentemente isso não é bom o suficiente para o Dotnet Core. Por que não podemos ter um XAML de plataforma cruzada sem atender a qualquer aspiração [imaginária] de "aparência e comportamento de plataforma padrão"?

Os principais obstáculos técnicos, eu presumo, seriam como fazer a interface "XAML" (ou qualquer que seja a plataforma de interface do usuário da próxima geração) com uma API 3D de plataforma cruzada - já que obviamente não podemos depender do Direct3D/Direct2D no MacOS etc. Mas eu presumo este problema foi resolvido pela Unity etc que conseguiu atingir esse objetivo.

Tem havido tanto arrasto da Microsoft sobre o assunto de código aberto da família de tecnologias XAML, é preciso se perguntar se escondido dentro dele há um cache secreto de bitcoins ou as chaves privadas para microsoft.com.

Continue com isso MSFT: Open Source WPF/Silverlight/WinRT-XAML e deixe a próxima era de ouro do UX começar.

É incrível ouvir o que você diz sobre Scott Hunter, @JackUkleja. Você tem fonte/link para isso? Se o que você diz é verdade, então, além do que você diz, isso mostra (surpreendente) ignorância em várias frentes:

1. Isso é exatamente o que o Xamarin.Forms tentou resolver.
2. UX/interações/estilos específicos da plataforma (ou imitando por assim dizer) são uma preocupação que pode e deve ser abordada por temas. É nisso que o WPF era muito bom (embora, para o seu ponto, possa e deva ser melhorado).
3. Pior de tudo, isso não coloca nenhuma confiança no grupo de talentos que criou com sucesso o WPF, sem dúvida a maior estrutura de apresentação de todos os tempos. Você está dizendo que eles não podem mais resolver esse problema? Ou pelo menos trabalhar a mesma mágica que tornou o WPF tão bem-sucedido de maneira multiplataforma?

Boa UX é boa UX. Como você aponta, a web demonstra isso claramente. Os usuários de aplicativos nativos estão definitivamente condicionados a uma certa aparência para suas interfaces nativas, mas, novamente, isso deve ser resolvido a partir de um tema.

Imagine poder visualizar um aplicativo em um dispositivo iOS em uma "skin" Droid (completa com comportamento) e vice-versa. Isso foi/é possível com o WPF e é exatamente o tipo de pensamento que deve ser levado adiante. Ou seja, a aparência/sensação/experiência não deve atrapalhar o desenvolvimento e o design do aplicativo. Você deve ser capaz de aplicar um tema, e walah, "simplesmente funciona". Infelizmente, isso foi/é um detrator para o Xamarin.Forms, pois, embora considere plataformas diferentes, há muito atrito envolvido em garantir que tudo funcione conforme o esperado em cada plataforma de destino.

@Mike-EEE Tenho certeza de que Scott Hunter disse palavras nesse sentido neste episódio dotnet rocks: https://www.dotnetrocks.com/?show=1291

Ré:

"o conjunto de talentos que criou com sucesso o WPF, sem dúvida a maior estrutura de apresentação de todos os tempos"

... meu entendimento é que um grande número de arquitetos originais, alguns dos envolvidos com o WPF, deixaram a MSFT e foram para o Google e se envolveram com o Angular. Muitas ideias do WPF estão aparecendo em frameworks Angular e relacionados, como templates. Mas não importa de que maneira você divida esses frameworks da web, acho que você sempre terá o cheiro de HTML/CSS em segundo plano. Nem todas as interfaces de usuário fazem sentido sendo baseadas em documento/semântica e essa é a natureza do HTML, e é por isso que eu acho que o mundo ainda pode fazer uso do "núcleo XAML".

[jack... não pense que os dados estão corretos sobre os arquitetos do google e do WPF]

@rrelyea Esse foi o meu entendimento, mas posso estar enganado. Eu poderia jurar que li que alguns da equipe do WPF trabalharam no Angular... Ian Ellison-Taylor entre outros? (Embora pareça que ele está de volta à MSFT agora...)

cheiro de HTML/CSS em segundo plano

Quanto mais conformidade e convergência para padrões HTML CSS unificados ou qualquer tipo de padrão a esse respeito (C, C++, JavaScript), melhor seria este mundo. Em vez disso, o XAML, com seu recurso exclusivo, pode se renderizar como uma estrutura de superconjunto para pilha HTML + CSS etc. lâmpada:

@jasonwilliams200OK FWIW/FYI já existe uma porta "padrão" HTML/CSS de .NET em JSIL . Toda a sua saída é 100% compatível com HTML5 e roda em qualquer navegador moderno. Este é o tipo de pensamento que devemos aspirar, é claro (e deveria ter sido o pensamento desde a morte do Silverlight em 2011, mas discordo).

Ou seja, (até o seu ponto, eu espero) o ideal/pedido é que os desenvolvedores .NET tenham que lidar apenas com .NET/C#/F#/VB.NET e nunca tenham que tocar no CSS/HTML/JS, assim como Os desenvolvedores do Xamarin .NET não precisam tocar nos fundamentos do iOS/Droid (o que quer que _eles_ sejam. :wink: ).

@Mike-EEE, em linguagens de superconjunto (TypeScript para JavaScript ou Less para CSS), podemos usar o código lang do subconjunto em superconjunto no mesmo arquivo, mas não o contrário. Assim, o conceito de superconjunto vai um pouco além de como phonegap, cordova etc. funcionam. :)

Haha sim @jasonwilliams200OK Eu só quero ter certeza de que não acabamos fazendo um caso especial para a nossa abordagem/estratégia ao colocar o .NET de volta no navegador. Tocar em CSS/JS deve ser visto com o mesmo desdém que tocar em binário. :stuck_out_tongue:

Como exemplo, há também outro projeto Fayde que usa Xaml (yay), mas também é dependente de TypeScript (boo). Esta é a maneira de NÃO fazer isso, pois você acaba tendo duas bases de código incompatíveis -- uma em TypeScript/JS para código de cliente, .NET para todo o resto -- o que é muito caro em tempo e recursos.

mecanismo de front-end alternativo para o Razor da ASPNET

Razor é apenas um mecanismo de modelo na minha opinião. De fato, naquele link que você mencionou, diz "... que você pode escolher entre uma longa lista de mecanismos de modelagem de front-end para codificar".

Eu até ouvi alguns comentários do MS contra sintaxes especiais do tipo C#, como Razor dentro da página HTML, em favor de estruturas que usam tags personalizadas

btw, há também Bridge.net (http://bridge.net) e outros compiladores C# para Javascript que podem ser combinados com soluções XAML como Fayde

Re XAML em HTML5/JS/etc. Existe um projeto interessante do Granular que está reimplementando o WPF. Ele usa Saltarelle para compilar para JS. Um exemplo vivo está aqui .

Esse Granular é fantástico, @ethanhs. Essa era uma que eu não conhecia. Como adotou a mesma abordagem CSHTML5 , JSIL, Bridge.net (que @birbilis menciona), sofre do mesmo problema de não poder compartilhar código entre servidor e cliente através do uso de PCLs, que é realmente o único viável maneira de fazê-lo nos dias de hoje.

E realmente, por melhor que o projeto pareça, ele resume o inferno que os desenvolvedores .NET tiveram que suportar desde o fim do Silverlight. Ele e cerca de uma dúzia de outros fazem "um pouco" trabalho de fazer o .NET funcionar no navegador, mas não exatamente a experiência completa que aqueles com experiência em Silverlight esperam.

Ainda não existe uma solução unificadora única e solitária que faça com que os desenvolvedores esqueçam o Silverlight. Estamos chegando mais perto, no entanto. Espero, pelo menos. O WebAssembly parece promissor, mas não tenho visto/ouvido nenhum desenvolvimento significativo há algum tempo. A porta/iniciativa orientada por JSIL parece ter desacelerado um pouco e não teve um check-in desde outubro passado.

Espero que tenhamos um avanço aqui no futuro próximo. Eu adoraria ver um anúncio feito no //build do próximo ano afirmando isso. :coração: :+1:

Essa seria uma das melhores coisas dos últimos anos acontecendo com o XAML.
Vote aqui !

Legal @bbougot. Há também outro voto, que _finalmente_ ganhou alguma atenção, depois de quase 15 meses de existência, sem contar os quase 3 anos de não reconhecer um sistema Xaml terrível para começar (mas eu discordo!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Sério, 15 meses para até mesmo reconhecer um voto para um dos problemas mais óbvios? O que a equipe UWP está fazendo lá??? Quando a equipe do Visual Studio ou .NET assumirá o controle e endireitará a nave??? O que será . .. oops, isso mesmo, eu estava divagando...)

Além disso, não se esqueça de votar neste tópico. Está indo muito bem @ 60 atualmente, especialmente considerando que esse problema começou antes de termos comodidades tão sofisticadas, como o GitHub Reactions. :sorrir:

O Xaml é o único com potencialidade de unificar todo o ecossistema do cliente!
Por favor, livre-se do DirectX, por favor, abrace o OpenGL!
UWP é para rodar no PC, no telefone, no site!
Viva Xaml!

Então, pergunta civil aqui @terrajobst , @harikmenon e @karelz (vejo que você adicionou uma tag recentemente, então parabéns, estou puxando você para isso!). Por simples curiosidade, decidi me aventurar um pouco e conferir a filtragem avançada (ou talvez não) do GitHub neste repositório. Pensando que houve muitos votos e que não para questões diferentes.

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

Parece que este problema tem 82 votos positivos atualmente, e se eu estiver correto, o próximo item mais próximo na lista está em 17. Isso torna este problema de longe o mais solicitado/votado neste repositório, correto?

Se sim, eu estava curioso para saber se isso tem alguma relação com suas prioridades e/ou planejamento. Claramente, isso parece ser uma pergunta/item _muito_ popular agora (novamente, se eu entendi corretamente), então estou pensando que talvez seja bom ouvir uma atualização ou check-in com relação a possivelmente iniciar uma conversa sobre o progresso em fazer esta questão uma possibilidade.

Seria ótimo obter qualquer perspectiva/contexto aqui e/ou se eu tiver algo completamente incompreendido em relação à demanda do cliente. Acontece. 😄

Nossos engenheiros do .NET Core estão fortemente focados no .NET Standard 2.0 (também com alta demanda do cliente) – veja detalhes aqui e aqui . Examinaremos outras bibliotecas que não estão nessa lista depois de atualizarmos o .NET Core para o padrão mais recente.

Obrigado por apontar a consulta de votos positivos!

Obrigado pela sua resposta @karelz! Muito apreciado. 👍

👼 👼 👼 Vou deixar isso aqui caso alguém queira curtir/retweetar. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

Trabalho com xaml desde a versão 3 do .net, senti o downsize do silverlight e até a sua morte. Eu sou alguém que adora mudanças para melhorar e tornar as coisas melhores e mais úteis. Mas agora, com a UWP, encontro regredir em vez de avançar. Não se importe com todos os novos recursos que são ótimos, mas com a falta de suporte completo ao xaml, como o aplicativo de desktop. Estou tentando fazer um novo aplicativo em UWP e aprendi da maneira mais difícil que tudo o que aprendi mudou novamente, não consigo encontrar muito suporte on-line, como para onde a biblioteca xaml foi movida. Por exemplo, o adornador que estava sob o framework não está mais lá, o x:static para as propriedades que não funcionam, você tem que procurar horas para encontrar um exemplo ou o que fazer. Não há link para mostrar a partir do xaml antigo para o novo UWP ...

@giworking É óbvio que a MS deve prestar atenção ao desenvolvimento do cliente! Como Satya Nadella é citado, o azul é o núcleo e o futuro do MS. A energia mais forte para impulsionar o azule é todo o ecossistema .net. Comparado com o java, o lado do cliente é quase a única arma para persuadir codificadores e empresas a adotar a nuvem da MS (na China, .net está realmente em uma condição catastrófica, as pessoas falam sobre java e reagem, "o que é f k s t xamarin?". ....). Então, como um codificador chinês, quando vejo xamarin, uwp, typescript e cshtml5, sei que é possível unir todo o lado do cliente no modo xaml+C#, mas por que nossos amigos do MS não veem a oportunidade de obter voltar a quota de mercado chinês com se?

Uau, esta edição já tem mais de 100 votos positivos! Muito obrigado a todos que demonstraram seu apoio. Se alguém estiver interessado, há um ótimo artigo de @terrajobst completo com seu tremendo envolvimento de desenvolvedor de marca registrada nos comentários aqui:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(Sério, todo funcionário da MSFT que publica uma postagem no blog da empresa deve seguir o exemplo do Sr. Landwerth sobre como postar e acompanhar os inevitáveis, inumeráveis ​​e incontáveis ​​comentários que surgem depois. Ele realmente está no topo de tudo e parece como muitos autores de MSFT simplesmente deixam suas postagens secarem e deixam as perguntas como mortas, o que, claro, é uma maneira terrível de tratar seu público!)

De qualquer forma, definitivamente vale a pena ler se você ainda não leu, especialmente os comentários. Isso me leva ao motivo pelo qual estou postando agora como _Estou muito satisfeito em ver esse problema mencionado nos comentários junto com a paixão/desejo de trazer o System.Xaml para a era do .NET Standard/plataforma cruzada_. 👍

154 votos positivos... e contando. 😎 A próxima edição mais alta está em 25 , para referência. #squeakywheel

Isso precisa ser feito. Vá em frente!

Temos um aplicativo @ReactWindows direcionado ao WPF no qual gostaríamos de usar o .NET Native para melhorar drasticamente a experiência de download/instalação pela primeira vez para nossas dezenas de milhares de usuários do Windows 7. Também temos planos futuros para trazer o React Native para o Linux e potencialmente reutilizar o código compartilhado @ReactWindows , mas segmentar o Xamarin.Forms.

Ter System.Xaml (e outras dependências de tipo/método/assembly do WindowsBase, PresentationCore e Xamarin.Forms) disponíveis no NETCore vNext é fundamental para essa estratégia. Podemos contornar essa deficiência criando e redirecionando os assemblies existentes ou preenchendo tipos/métodos ausentes no System.Xaml do Mono e compilando-o para .NET Core, mas realmente preferiria que a Microsoft avançasse e fornecesse o que é necessário para a plataforma. /cc @rozele @pre10der89

@matthargett Boa sorte nisso. Eu venci esse problema até a morte quando estava pensando em trazer o fluxo de trabalho para o .net core. Até chegou ao ponto de entrar em contato com a equipe xaml. Eles não estão nem remotamente interessados ​​em abrir o System.Xaml. Não entendo por que - certamente não há nada que valha a pena proteger lá.

Pode ser que isso seja considerado após o lançamento da versão 2.0 no final de abril.

Pessoal, novamente, não precisamos do System.XAML para fazer o WF portado para netstandard1.x ... Já existe um bom trabalho do @dmetzgar no qual o core do WF funciona. A principal peça que falta são as transações, que acredito voltarão eventualmente em netstandard2.x .

A principal diretriz do port @dmetzgar é não ter nenhum tipo de linguagem de design vinculada ao núcleo e ter primitivos básicos para que as pessoas possam serializar o fluxo de trabalho o que quiserem e, posteriormente, criar designers em cima dele.

É claro que essa abordagem levará à não compatibilidade com versões anteriores com os fluxos de trabalho atuais baseados em XAML, mas acredite em mim, mover qualquer coisa para o .Net Core É uma grande mudança revolucionária, então as pessoas precisam entender isso.

Existe o OminiSharp que pode ser aproveitado para os designers XAML, mas, novamente, o design/serialização está fora do núcleo do WF. Deve ser fino como todo o resto com .Net Core.

Eu diria que esse problema fez bem alto que as pessoas querem mover o WF para o .Net Core, só acho que reclamar com a equipe do System.XAML para o OSS dele, simplesmente não está sendo produtivo. A equipe XAML tem outras prioridades e é essencial para os negócios do Windows/UWP/Xamarin, portanto, não espere que seja OSS tão cedo. Em vez disso, eu pediria a @dmetzgar para tornar oficialmente público o repositório do WF sob a .Net Foundation, e orientar a comunidade para colocá-lo em funcionamento sem definir nenhum cronograma ou promessas de liberação de netstandard2.x . Seria um trabalho contínuo conduzido por sua equipe e ajudado principalmente pela comunidade que claramente quer ajudar e sair.

Veja como as coisas evoluem rápido no projeto Orleans... Foi uma pesquisa da Microsoft que foi OSSed no ano passado e é um dos maiores e mais ativos repositórios da .Net Foundation e é principalmente impulsionado pelos esforços da comunidade (ainda tem um equipe MSFT trabalhando em tempo integral nele).

De qualquer forma, IMHO, acho que precisamos parar de falar e começar a fazer alguma coisa. É claro que a equipe @dmetzgar não tem largura de banda para trabalhar nisso, pois suas principais preocupações são apoiar os principais usuários do WF, que são basicamente grandes implantações do Sharepoint que não têm planos de chegar ao núcleo .net. Portanto, deve ser um esforço conduzido pela comunidade (supervisionado pela equipe de @dmetzgar ).

Pessoal, novamente, não precisamos do System.XAML para fazer o WF portado para netstandard1.x...

@galvesribeiro isso pode ser verdade, mas esse problema é fazer a portabilidade do System.Xaml para o .NET Core, do qual é de longe o recurso mais solicitado no repositório onde a equipe do .NET está solicitando comentários. Se você não ouve seu feedback, então por que solicitá-lo? De qualquer forma, o WF é simplesmente _um_ dos cenários que uma porta System.Xaml satisfaria. Como você sabe (ou deveria!) System.Xaml é capaz de muito mais.

A equipe XAML tem outras prioridades e é essencial para os negócios do Windows/UWP/Xamarin, portanto, não espere que seja OSS tão cedo.

Sim, esse é um tipo de problema aqui e o que estamos pedindo para mudar. :) Além disso, eu nem tenho certeza se existe mais uma "Equipe Xaml" hoje em dia, não é?! Realmente parece que essa tecnologia foi fechada e estamos começando a dar uma volta nela.

De qualquer forma, IMHO, acho que precisamos parar de falar e começar a fazer alguma coisa.

100% de acordo. FWIW, @SuperJMN acaba de lançar OmniXamlv2.0 , então há alguns esforços da comunidade em andamento que podem ser aproveitados enquanto a MSFT prioriza suas energias e esforços em torno desse problema (que, aliás, está acontecendo há cerca de 11 meses - e contando).

Falando nisso, aqui está um bom tópico exatamente sobre isso (ou seja, a inatividade da MSFT sobre isso), com uma citação de @terrajobst :

Para ser claro, não estou dizendo que System.Xaml não pode ou não deve ser multiplataforma. O que estou dizendo é que System.Xaml não é muito útil fora do WPF e WF, e o NuGet é uma métrica de proxy sensata para essa instrução. É claro que System.Xaml pode ter significado fora do domínio da interface do usuário, mas essa é uma etapa secundária. Prefiro usar nossos recursos AGORA MESMO para fazer com que as peças fundamentais funcionem bem e sejam completas. Além disso, por ter uma base convergente, a portabilidade de componentes de nível superior, como System.Xaml, também se torna muito mais fácil.

Portanto, não é uma declaração do tipo ou-ou; é uma declaração de ordem de execução.

Deixando de lado a declaração muito incorreta sobre System.Xaml não ser útil fora do WPF/WF, tudo isso soa como gerente de projeto para mim, sem intenção de resolver esse problema. Meu objetivo não é ser crítico com essa declaração, pois apoio totalmente Immo e o ótimo trabalho que ele faz aqui. No entanto, tenho andado o suficiente para permitir que esse tipo de linguagem me dê uma pausa e me coloque em uma posição de esperar para ver (ou melhor, "acreditar quando vejo" LOL!) em relação a esse problema.

Enquanto isso, apoio os esforços atuais no .NET Standard 2.0 e aguardo com expectativa o que isso trará. Talvez seja melhor do que o esperado. No mínimo, parece que seremos capazes de recuperar projetos System.Xaml para .NET Core trabalhando em plataformas Windows, o que é um bom começo para mim. 👍

@Mike-EEE em primeiro lugar, desculpe... Eu pensei que estava respondendo a isso https://github.com/dotnet/corefx/issues/2394 oO Esses dois problemas foram correlacionados muitas vezes que fiquei confuso.

Em segundo lugar, não estou dizendo que o XAML é útil apenas para a interface do usuário. Usei-o por muitos anos em compilações do TFS, no próprio WF e, recentemente, na interface do usuário. Há várias DSLs como o Azure ML e outras que podem aproveitar o XAML.

O que eu quis dizer é que não estou vendo XAML sendo portado tão cedo para .Net Core. Como Immo disse, eles precisam acertar primeiro com as plataformas atuais. O .Net Core ainda não possui nenhuma biblioteca nativa de manipulação de imagens.

Existem várias implementações de XAML que variam de WPF com recursos completos a fracos e sem muitos recursos em UWP. Deve ser unificado e estabilizado antes que tal coisa tenha OSS. Eu não falo pelas equipes que trabalham nele. Só acho que não faria diferente do que eles se tivesse que priorizar meus recursos.

Com relação ao WF, desculpe novamente, mas meu comentário anterior foi principalmente direcionado para aqueles que esperam que esse problema seja o motivo pelo qual a porta do WF para o núcleo não está acontecendo tão rápido, o que não é verdade .

Essas duas questões foram correlacionadas muitas vezes que eu fiquei confuso.

Haha @galvesribeiro não sei te dizer (ou tenho medo de admitir) quantas vezes isso me mordeu também. Não se preocupe com isso. Eu, pelo menos, aprecio a entrada independentemente!

FWIW, também parece que @cwensley continua a fazer um ótimo trabalho em @ Portable.Xaml , tendo recentemente feito melhorias de desempenho em sua adaptação baseada em mono do System.Xaml que o torna mais rápido que a versão original. Quase parece que isso poderia ser um bom ponto de partida para um esforço aqui, já que provavelmente está mais próximo da experiência original do System.Xaml de todos os sabores/opções disponíveis. Apenas meus dois centavos induzidos pela cafeína pela manhã.

Por favor, transfira System.Xaml para .NetCore

FWIW, mais de 200 votos para esta questão, agora com 202. A próxima questão mais alta é dotnet/corefx#13526 com 47. Bem, ERA 47... agora são 48 depois do meu voto. :) (Vá mostrar um pouco de amor, é uma boa ideia.) #squeakywheel

Obrigado pelo lembrete @Mike-EEE ;-). Para definir a expectativa: ainda não estamos prontos para começar a cavar profundamente - eu pessoalmente espero que até março possamos comentar mais sobre nossos próximos passos oficiais, mesmo que seja novamente "ainda não temos planos" (disclaimer: estou tentando comunicar meu melhor palpite pessoal, por favor, não trate isso como promessa oficial da equipe!).

Quando discutimos a questão um pouco da última vez, a questão-chave que surgiu foi determinar quais dos mais de 200 votos são realmente apenas sobre System.Xaml vs. WPF. A suposição é que muitas pessoas não distinguem entre os dois. Alguma sugestão de qual a melhor forma de fazer isso? (por exemplo, criando 2 problemas específicos e pedindo às pessoas que votem no WPF versus "Xaml puro, não WPF")

Também ajudaria ter uma lista resumida de cenários para System.Xaml com algumas estimativas de prioridade (agora elas estão espalhadas por uma longa discussão). @Mike-EEE é algo que você poderia nos ajudar a montar, por favor? (pois você parece ter forte interesse e profundo conhecimento na área)

Definitivamente System.Xaml é o que as pessoas querem @karelz. Se alguém está pensando em WPF aqui não é o lugar certo IMHO. Existem vários outros frameworks que utilizam XAML como WF, TFS Build, etc que ainda usam System.Xaml e isso nos daria uma grande ajuda.

@karelz Eu realmente aprecio sua resposta aqui. Obrigado por tomar o tempo para fazê-lo. Como @galvesribeiro menciona, System.Xaml é mais do que apenas UI, o que parece ser um entendimento chave que é perdido por muitos MSFT, infelizmente. É um paradigma de serialização poderoso que o coloca acima e além de qualquer outra solução de serialização existente, especialmente e particularmente quando se trata de descrever aplicativos, que é o que é melhor em fazer (afinal, o "A" em seu apelido). Infelizmente, "aplicativo" foi confundido com "UI" e, portanto, o atrito aqui.

Negligenciar esse aspecto foi uma falha fundamental da UWP e é parte do motivo pelo qual ninguém gosta de trabalhar com ela. Por outro lado, o Xamarin parece ter entendido esse aspecto-chave em seu sabor de Xaml, mas é interno e não é exposto como uma oferta autoritária de primeira classe deveria ser (que é basicamente o que esse problema busca aqui).

TBH, o port do System.Xaml de @cwensley em Portable.Xaml parece ser o favorito no momento. Ele não apenas portou o System.Xaml do Mono (mantendo sua API familiar geral), mas adicionou novos recursos e melhorou seu desempenho para ser _melhor_ que o do System.Xaml.

Na minha opinião, esse problema pode ser tão simples quanto trabalhar com @cwensley para fazer com que ele seja a biblioteca Xaml de plataforma cruzada autorizada para usar daqui para frente.

Fora disso, é onde fica complicado e pode estar adicionando à sua visão (compreensivelmente) complicada desse problema. Como o System.Xaml fornece uma linguagem expressiva e poderosa para descrever aplicativos (novamente, não apenas interfaces de usuário), ele também tem um ótimo suporte de ferramentas incorporado ao Visual Studio (e, claro, ao Blend). Então, idealmente, seria incrível continuar essa mesma ótima experiência e, de alguma forma, manter a experiência do designer do Xaml em uma maneira multiplataforma, mas pessoalmente isso é pedir uma cereja no topo do bolo incrível que estamos discutindo aqui. :)

Além disso, para reiterar aqui, a promessa (e entrega) do Xaml também foi uma melhoria do fluxo de trabalho de desenvolvimento entre designer e desenvolvedor. Gosto de pensar que podemos dar um passo adiante e melhorar o processo entre desenvolvimento e _devops_. Ou seja, eu adoraria ver um mundo onde o devops funciona em editores de configuração de aplicativos lindamente projetados (com tecnologia Xaml) para gerenciar e manter aplicativos implantados.

_A ideia aqui é reduzir o custo geral no desenvolvimento de aplicativos, desde a codificação até a implantação. Trabalhar com editores e designers bonitos é mais barato (do ponto de vista dos recursos) do que ter que encontrar e empregar alguém que precisa colocar as mãos no código (e/ou scripts) para fazer a mágica acontecer._

Eu compartilho isso com você como uma perspectiva de visão, apenas para que você esteja ciente. Eu não tenho certeza do quanto você está interessado em ouvir isso, no entanto. 😉 Então, se isso é simplesmente um "o que seria necessário para fechar esse problema e fazer você ir embora?" Eu sugeriria explorar a possibilidade de trabalhar com o Sr. Wensley e ver se podemos alavancar seu ótimo trabalho até agora (ou se ele está aberto a fazê-lo). Se houver uma maneira de dobrar isso para que possa ser o pacote Xaml de plataforma cruzada autoritativo para o lançamento do .NET Core Wave 2 (por volta de maio?) então melhor ainda. :)

Obrigado pela informação, estou definitivamente interessado. Eu também sinto que minhas perguntas anteriores não vieram como eu pretendia, então deixe-me tentar apontar algumas coisas:

Sim, estou definitivamente interessado em detalhes. Eu não acho que alguém esteja contestando Xaml != WPF no lado do MSFT. Eu definitivamente não tentei fazer isso. Eu só sei o que não entendo completamente, e estou tentando preencher as lacunas - ou seja, entender completamente a motivação e a necessidade dos cenários de "Xaml puro".
(BTW: Eu não entendo muito bem o seu cenário devops e como o Xaml é a única/melhor coisa para ajudar lá? Ou como ele é realmente usado no cenário?)

Não estou aqui para tentar encerrar este assunto. Por favor! Isso nem me passou pela cabeça. Estou aqui para ajudar a comunidade a resumir a pergunta, de modo que possa ser discutida com as pessoas certas (pense nos diretores neste caso). Sim, parte disso significa que eu (e/ou alguns outros MSFTs) temos que entender completamente o pedido para representá-lo mais alto - daí minhas perguntas.

Admito que sou um bom exemplo de uma pessoa que não distinguiu Xaml e WPF antes de ver esse problema. De bate-papos aleatórios com outras pessoas da equipe .NET, muitos sabem que Xaml != WPF, mas eles não veem o "grande valor" de ter Xaml puro que está sendo apresentado aqui - portanto, minhas perguntas acima sobre os cenários. Os cenários ajudarão a mim/nós a entender melhor a motivação e a contar/vender melhor a história. (Espero que não seja uma surpresa que, quando não há uma história clara, ninguém se sinta ansioso para financiá-la :) - a história é um pré-requisito para financiamento)
Então, vamos criar o passo do elevador para movê-lo para a frente.

Em relação ao trabalho de @cwensley - é ótimo saber que pode haver algumas soluções não tão caras. Mas, novamente, realmente ajudaria primeiro entender o histórico e o PORQUÊ, antes de pular para a solução. Eu espero que faça sentido. (Não estou tentando ser desdenhoso nem nada - apenas repetindo que é mais fácil avançar quando o PORQUÊ é entendido e acordado)

@galvesribeiro Se alguém está pensando em WPF aqui não é o lugar certo IMHO

Eu não compartilho de sua confiança de que todas as mais de 200 pessoas que votaram realmente entendem o Xaml != WPF para tais detalhes. Também acho que pelo menos alguns olham para ele - sim, vamos obter o Xaml primeiro, será mais fácil pedir o WPF. Portanto, o cenário deles em mente o tempo todo é o WPF, enquanto o "Xaml puro" é apenas o primeiro passo para isso.
E talvez eu esteja errado (embora eu pelo menos não seja a única pessoa na equipe .NET com essas dúvidas)...
Outro ângulo pode ser dividir o "Xaml puro" em uma lista de cenários (WPF, devops acima, talvez mais alguns?) e depois pedir às pessoas que votem neles - Qual deles realmente importa para aqueles que votaram aqui? O que eles realmente querem?
(Esta não é uma tática de atraso, ou qualquer coisa ruim, estou tentando entender o "cliente" aqui. Espero que faça sentido - se você tiver sugestões melhores de como obter esses dados, fale, estou aberto a abordagens alternativas )

EDIT: Como de costume, se você acha que não estou abordando o problema da maneira certa, por favor, diga. Estou tentando fazer o meu melhor aqui para ajudar - com as melhores intenções. Não sofro da ilusão de saber tudo, ou pensar que sou mais inteligente do que todo mundo.

@karelz Existem várias estruturas de interface do usuário que estão reinventando a roda e escrevendo suas próprias linguagens de marcação apenas porque o XAML não é multiplataforma, mesmo que não goste do WPF. Avalonia é um dos melhores. Eles usam o Omnisharp quando poderiam estar aproveitando o XAML nativo.

Workflow Foundation é um grande usuário/cliente de XAML e as pessoas no segmento Port WF to .Net Core sempre perguntam sobre isso.

Então, sim, concordo com você que devemos estabelecer as expectativas ou desenhar um conjunto de recursos brutos sobre o que é esperado da plataforma cruzada System.Xaml junto com os usos desejados, como, por exemplo, UI e WF.

@karelz

Também acho que pelo menos alguns olham para ele - sim, vamos obter o Xaml primeiro, será mais fácil pedir o WPF. Portanto, o cenário deles em mente o tempo todo é o WPF, enquanto o "Xaml puro" é apenas o primeiro passo para isso.
E talvez eu esteja errado (embora eu pelo menos não seja a única pessoa na equipe .NET com essas dúvidas)...

Então... qual é o problema com isso? Uma solução de plataforma cruzada semelhante ao WPF pode ser uma coisa muito boa. O Xamarin não pode fazer GUI de área de trabalho de plataforma cruzada.

@jnm2 não é ruim - mas se esse for o cenário principal (90%+), devemos planejar fazer os dois. Ter Xaml sem o WPF não vai ajudar nesse caso (pelo menos não muito). E pode criar (potencialmente) ilusão inválida de que o WPF está confirmado e virá logo depois.

Colocar o WPF/GUI no .NET Core será um grande passo para o .NET Core, que agora visa principalmente cenários de servidor e aplicativos de console.

@jnm2 tendo System.Xaml ajudaria massivamente pessoas (como eu) que estão _tentando_ trazer algo como WPF para outras plataformas (https://github.com/AvaloniaUI/Avalonia).

@grokys isso soa como um cenário razoável - você pode elaborar um pouco mais sobre isso? Quão massiva seria a ajuda? O que é desafiador sem ele?

Também estou usando Xaml para minha estrutura de interface do usuário de área de trabalho de plataforma cruzada (não semelhante a WPF), Eto.Forms . É por isso que eu criei o projeto Portable.Xaml para começar, e tem funcionado bem para mim e meus usuários até agora.

Não me oponho a ajudar a tornar isso a implementação xaml "autoritária" de plataforma cruzada (como @Mike-EEE coloca). No entanto, lembre-se de que só trabalho com isso no meu tempo livre (;

@karelz
Não apenas estruturas de interface do usuário, pode ser usado em muitas cenas, como XAML para HTML

@Kation você pode compartilhar mais detalhes do que exatamente você quer dizer?

BTW: Comecei a resumir cenários no post principal - se o seu cenário não estiver lá, descreva-o e, uma vez entendido, vou adicioná-lo lá.

@karelz
Com o poderoso editor XAML no visual studio, podemos criar rapidamente conteúdo de componentes personalizados.
Então, acho que poderíamos usar XAML para gerar conteúdo HTML em algum cenário especial, ainda mais conteúdo SVG.
Esta é uma estrutura XAML para XML semi-acabada para .Net 4.5. https://github.com/Kation/WebPresentation

Não entendo por que você deseja gerar HTML ou SVG de XAML. Qual é o valor do XAML aqui?
O valor é que tem um bom editor VS? Existem também editores de HTML, por que não usá-los diretamente?
Ou estou perdendo completamente o ponto?

@karelz
Porque eu quero gerar conteúdos como WPF com template e estilo em alguns projetos.

@karelz obrigado novamente pelo diálogo. Eu, pelo menos, aprecio muito.

Não sofro da ilusão de saber tudo, ou pensar que sou mais inteligente do que todo mundo.

Ah, eu invejo. 😉

Portanto, o cenário deles em mente o tempo todo é o WPF, enquanto o "Xaml puro" é apenas o primeiro passo para isso.

Sim, esta é novamente a confusão que mencionei. Xaml é um paradigma de serialização, puro e simples. Você pode definir e descrever um aplicativo -- e seus componentes -- nele. Para começar, aqui está um exemplo de um _aplicativo de console_ descrito em Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Você pode ver que existem comandos descritos em Xaml que fornecem instruções sobre o que apresentar ao usuário por meio do uso de entradas e saídas do console. Isso não tem nada a ver com WPF ou "UI" (embora tecnicamente essa seja a interface do usuário no sentido de a CLI ser a interface do usuário, mas espero que você possa identificar a diferença). Além disso, você pode ver que eu uso extensões de marcação e declarações de membros estáticas diretamente no arquivo. Isso é algo que eu não vi em JSON ou em qualquer outro formato de dados. Este é realmente o poder do Xaml, IMO.

Como outro exemplo de um cenário "Pure Xaml", aqui está o arquivo que estou propondo para um novo MSBuild independente de formato:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(se você subir um nível, poderá ver os outros formatos que fazem a mesma coisa, essa é a versão Xaml)

Este é o arquivo do processador que novamente é um conjunto de comandos ( System.Windows.Input.ICommand ) que descrevem as etapas a serem seguidas em um processo de construção teórica. Novamente, nenhum WPF ou UI, mas você pode ver que ele emite mensagens para o console.

Um recurso que quero destacar aqui que mencionei anteriormente é o conjunto de ferramentas interno no Visual Studio que recebo deste arquivo:

Sem fazer nenhum trabalho ou definir qualquer esquema externo, o Visual Studio simplesmente "acende" e fornece editores de propriedades completos com menus suspensos e outra interface de designer com base no esquema de classe do arquivo com o qual estou trabalhando (esperamos que isso facilite o cenário de devops para entender).

Além do arquivo do processador, aqui está o projeto teórico ou arquivo de entrada que pode ser usado para enviar ao processador:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Aqui eu tento acertar o ponto inicial com _extensões de marcação_ usadas para fornecer uma versão (concebivelmente de um arquivo externo) e também usar uma consulta para fornecer os arquivos coletados para compilação (observe que talvez você não queira realmente fazer isso em um sistema de compilação final, mas eu queria demonstrar sua possibilidade).

BTW, este código de exemplo está totalmente operacional, então você deve ser capaz de obter o SLN desse repositório e executar a versão Xaml, os resultados devem ser parecidos com o seguinte:

(Nota: Funciona no My Machine , então sua milhagem pode variar. 😄)

BTW: Eu não entendo muito bem o seu cenário de devops e como o Xaml é a única/melhor coisa para ajudar lá? Ou como ele é realmente usado no cenário?

Sim, eu debati se deveria entrar nisso, pois senti que meu post estava ficando um pouco longo. Espero que agora o componente de designer visual acima possa ajudar a ilustrar o que estou tentando fazer aqui.

Por favor, saiba e observe que para mim este é o jogo final final e por que estou tão entusiasmado com tudo isso. _O motivo é que acaba reduzindo o custo total de propriedade de um aplicativo ao longo de sua vida útil._

Então, no núcleo aqui, o que estamos falando aqui é o desenvolvimento baseado em POCO, onde a edição e o design ocorrem em POCOs usados ​​em um processo de aplicação. Como sabemos, um desenvolvedor e designer trabalhará em um arquivo Xaml que descreve os elementos POCO que lidam com o domínio da interface do usuário (aqui está o tradicional "WPF" de "Xaml", se você preferir).

No meu mundo, eu gostaria de ver esse processo estendido para que o desenvolvimento entregasse arquivos Xaml para devops usarem para gerenciar/manter aplicativos que foram implantados em um ambiente ativo.

Você pode pensar nisso como arquivos de configuração ao vivo. Como eles são carregados terá que ser resolvido, mas o resultado final seria algo como o que você vê na captura de tela acima no Visual Studio. Em vez de o usuário final (devops) ser forçado a colocar as mãos no código (ou melhor, ter uma organização sendo forçada a contratar o caro talento/habilidade necessário para tal), eles trabalham com controles de edição visual validados e restritos para configurar e manter o aplicativo.

_A ideia aqui é que, devido ao esforço (e habilidade) necessário para fazer isso, em vez de conhecer e entender o código, o custo de manutenção de um aplicativo após a implantação é reduzido consideravelmente._

Um aspecto que não mencionei sobre isso é que esses controles são realmente personalizáveis. O Visual Studio possui uma API extensa (embora antiga) para definir os editores visuais anexados a essas propriedades POCO:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

Tudo isso está disponível agora no Visual Studio sem nenhum trabalho, sobrecarga ou esforço adicional. Portanto, a ideia final aqui seria criar um conjunto de editores e designers poderosos para ajudar não apenas no processo de desenvolvimento, mas também no processo de devops.

Novamente, tudo isso é visionário e sem nenhuma base real no mundo real (ainda). Para ter certeza, isso não é totalmente minha ideia, mas é inspirado no grupo de padrões e práticas com seu Editor de configuração baseado em Windows Forms . Eu simplesmente levei esse otário um passo adiante e vi o uso disso através do poder do Xaml.

Por favor, deixe-me saber se você tiver alguma dúvida adicional sobre este @karelz. Mais uma vez eu aprecio o diálogo. Não apenas oferece a oportunidade de compartilhar, mas também dá a oportunidade de validar minhas ideias e crenças. E voltando à ideia de saber tudo (sim, sou culpado 👼), tento manter a mente aberta sobre as coisas e perceber que não tenho todas as respostas. Este é definitivamente um processo que estou continuamente tentando melhorar. Obrigado novamente!

@karelz - Avalonia atualmente usa OmniXaml como seu mecanismo XAML e, embora isso funcione muito bem, ainda existem bugs e recursos ausentes. Assim como o Portable.Xaml, o OmniXaml é mantido por um voluntário que nem sempre tem muito tempo para trabalhar nele.

Se de fato você decidir não abrir o System.Xaml, talvez liberar seu conjunto de testes seja um bom compromisso - pelo menos dessa forma poderíamos garantir que as implementações de terceiros, como OmniXaml e Portable.Xaml, fossem tão compatíveis quanto possível.

Eu acho que o ecossistema .net precisa é de um formato de serialização legível por humanos padrão - algo como JSON no mundo Javascript. Esse formato deve usar tipos de dados donet e usar POCOs diretamente como esquema. Então esse formato pode ser usado para descrever objetos POCO. Essas descrições são fortemente e estaticamente tipadas. Que pode ser um layout de interface do usuário, configuração de aplicativo em tempo de execução, descrição de projeto/fluxo de trabalho ou até mesmo para comunicação entre dois programas .net. E até a comunicação com outros ecossistemas (como web/Javascript) também é possível, desde que implementem o formato. Mas deve ser projetado em torno do ecossistema .net. É por isso que JSON/BOND/Protobuf/XML não é suficiente.

Historicamente, o XAML cumpria de certa forma a responsabilidade. Agora a questão é, quão bom é para este papel. Se for bom o suficiente, então eu acho que o XAML deveria se transformar em implementações netstandard e .net. Mas, se possível, outros formatos também devem ser levados em consideração. Acho que na semana passada, http://www.ammyui.com/ saiu. Um formato de descrição de interface do usuário focado na simplicidade, mas se traduz em XAML. Porque, XAML não era simples o suficiente. Eu mesmo propus um formato em roslyn repodotnet/roslyn#16648 baseado em inicializadores (objeto, coleção e índice). E minha proposta foi realmente tirada (e depois ligeiramente modificada) desta postagem no blog de @bricelam da equipe do Entity framework. Tanto o post dele quanto o tópico da minha proposta têm alguns exemplos.

Meu ponto é, deve haver um formato padrão para .net, seja XAML ou qualquer outra coisa.

@grokys Eu queria mencionar OmniXaml e convidei @SuperJMN para a conversa aqui, mas parece que ele nunca quer participar. Não tenho certeza se são configurações ou o que (eu também fiz uma tentativa no gitter - já que você trabalha com ele, talvez você possa ter mais sorte em arrastá-lo aqui 😄). Obviamente, OmniXaml também é bem-vindo a esta conversa.

@gulshan +💯 👏 👏! Ha ha. Parte da parte confusa de tudo isso é que o Xaml É um formato e tecnologia MSFT. Com todos os investimentos e ferramentas construídos em torno dele - tanto com MSFT quanto em empresas, é realmente incompreensível por que parece haver uma lacuna em garantir sua continuidade para que os esforços e investimentos existentes possam ser aproveitados.

Dito isto, gosto do que vejo com Ammy e continuo com a mente aberta sobre isso. Ou tente ter um. 👼

Acho importante reiterar por que nos preocupamos com arquivos de dados para começar, o principal valor no uso de formatos de dados é:

• Imperativo Linguagem Agnóstica . O uso dos arquivos não exige que você conheça uma linguagem de programação.
• Designer/ferramenta amigável. _Usar um designer visual e/ou permitir uma experiência de designer visual com seu produto leva a um TCO menor _.

Dito isto, o que é pessoalmente importante para mim é:

• Fluxo de trabalho integrado de desenvolvedor/designer
• Experiência de designer visual para arquivos de edição manual.
  
  
  
  • PropertyGrid (Janela de Propriedades) com API de editor extensível, conforme discutido acima.
  
  
• Extensões de marcação
• A cereja no topo do bolo incrível: Capacidade de aproveitar todos os itens acima em cenários fora do desenvolvimento (exemplo de devops acima).

Se todos estes forem atendidos, então eu estaria disposto a considerar "outro formato .NET", mas obviamente eu preferiria manter e estender o Xaml como esse formato. É uma tecnologia MSFT e, portanto, propriedade intelectual, afinal.

@Mike-EEE Se um formato puder ser desserializado para um POCO, todos esses recursos devem estar funcionando. A janela de propriedades no VS também aparece para cenários não XAML. Mas uma coisa que me preocupa é a legibilidade sem nenhum suporte do editor. Em alguns casos, você precisa editar um arquivo de configuração em um servidor remoto e só tem o vim. Comparado ao JSON, XML (e XAML) não é tão bom nesse sentido, IMHO.

Mas o XAML tem algumas coisas únicas (na verdade, recursos não XML), como propriedades anexadas, que são difíceis de imitar em um formato de serialização simples.

Eu votaria primeiro no WPF (para que eu possa finalmente dizer adeus ao xamarin.froms), depois no xaml

A janela de propriedades no VS também aparece para cenários não XAML

Correto, mas não é quase "aceso" como é para Xaml, com controles de edição totalmente personalizáveis, etc. Corrija-me se eu estiver errado aqui. Você não pode simplesmente colocar o cursor em uma propriedade nesses formatos e ter uma renderização suspensa para um campo de enumeração (por exemplo). Essa experiência é basicamente a próxima forma e versão do WinForms, o que é parte do motivo de ser tão bom (o WinForms ainda é popular!).

Comparado ao JSON, XML (e XAML) não é tão bom nesse sentido, IMHO.

Sim, eu concordo, o Xaml não é exatamente conciso, e você ouvirá reclamações sobre o quão detalhado ele é. É aqui que o OmniXaml está deixando sua marca, fornecendo melhorias na formatação. Você também está competindo com outros formatos como TOML e YAML e outros.

recursos não XML) como propriedades anexadas ...

E extensões de marcação. 😄 Essas são características de sua visão.

O que (eu acredito) você está mexendo aqui @gulshan é essencialmente um "Data AST (árvore de sintaxe abstrata)". Se estamos falando de melhorar seriamente o Xaml (ou formato de dados .NET), então este é o caminho a seguir. Poderia ser alimentado por Roslyn, até. Na verdade, eu tenho um voto de usuário para essa ideia (junto com uma postagem de blog correspondente ). Infelizmente não é muito popular, pois é meio difícil de explicar, haha. Essencialmente, você tem uma árvore AST (dados) que pode ser gravada em qualquer número de formatos. Dessa forma, os desenvolvedores (e ferramentas) podem trabalhar com ele de acordo com qualquer formato que faça mais sentido (esteticamente ou não) para eles.

para que eu possa finalmente dizer adeus ao xamarin.froms

De acordo com você nesse aspecto @groege. 😎

@Mike-EEE Ainda não verificou sua proposta de Data AST. Sim, é conceitualmente semelhante à proposta padrão de serialização/notação de objeto para .net. A ideia é difícil de entender por causa de sua abstração. 😄

Com relação ao XAML, um formato de serialização de dados fortemente tipado baseado em .net aliviará a necessidade de muitas extensões de marcação XAML. Ainda restarão alguns, que não podem ser inicializados por alguma expressão (sem construtores). Gostaria que alguns desses recursos de extensão de marcação fizessem parte do próprio C#.

Bem, eu não ouvi de volta de @karelz , então só posso supor que ele já esteve empoleirado na frente de seu monitor ao saber que você pode definir um aplicativo de console em Xaml:

Piadas (ruins) à parte, por favor, deixe-me saber se você tiver alguma dúvida adicional.

Além disso, de This Week in .NET, parece um mecanismo muito legal que está sendo desenvolvido no .NET Core . O primeiro comentário deste post diz tudo . :)

@Mike-EEE Eu sei que devo uma resposta a você (está marcado como importante na minha caixa de entrada e aberto no navegador).
Até agora eu só consegui dar uma olhada nas respostas (muito obrigado a todos por todos os detalhes e insights!), mas não tive tempo de me educar no Xaml (como você aponta) e ler todas as respostas cuidadosamente para ser capaz de responder... desculpe, muitos incêndios e altos prisões acontecendo agora :(, vou chegar a isso mais tarde, prometo!

Tudo de bom @karelz! Muito aprecio seus esforços e diálogo aqui.

Aqui está um voto para o WPF de código aberto, todas as outras versões do XAML são lixo em comparação. E sério pessoal, completem o loop nisso, tenham um .net core/XAML STORE para unix e MacOS.

@Mike-EEE desculpe, ainda não tive tempo de voltar a este problema :(

Oh cara, não se preocupe com isso, @karelz , eu sei que todo mundo está ocupado agora. Eu aprecio a conversa mais do que qualquer coisa. Eu tirei muito da minha cabeça. É bom ver isso por aí e refletir sobre isso como tal. Além disso, nós já colocamos mais de um ano de espera nisso até agora... o que são mais alguns meses? :)

eles deveriam opensource silverlight 5 .. desde seu html5 move, seu win8 move/winrt...& agora uwp & win10 e xamarin .... COMUM!! patético seu perdido em la la land como hollywood ou o que ...

como alguém pode ir de silverlight 5 para todas essas porcarias? COMO? como você pode dizer que respeita seus usuários quando você sempre quebra interfaces de montagem .. você até renomeia seu próprio pacote nuget e não fornece uma maneira automática de passar do antigo para o novo no nuget .. beta tester porque você é muito burro para pensar claramente antes de criar as ideias e codificá-las.

você precisa remover a necessidade de projetos ios/android/uwp em formulários xamarin.. PENSE que há maneiras muito melhores de suportar multiplataforma do que ter um projeto para cada plataforma.

agora traga tudo sob um f. framework you ass wipes (eu recomendo cobertura wpf/silverlight e linguagem xaml, mas se você quiser trazer tudo para o xamarin, por favor, você pode adicionar tipos de dados no estilo/modelos .. omissão estranha como muitos e certifique-se de que seu f. nucrapget funcione A1 por uma vez .. por que diabos eu precisaria instalar um pacote nuget em todos os assemblies dependentes? mesmo com dll referenciado .. ? você não tem visão ... niet none ... capout ... todo esse tempo preso na porcaria do ms .. eu poderia ter construído meus próprios sdks de classe mundial ..

eu não posso passar um dia sem MS despejando uma merda na minha estrada .. estou pensando seriamente em scala-js ou apenas swift .. é hora de sair de casa! Estou farto

Bem, eles levaram quase dois anos, mas a UWP finalmente está especificando extensões de marcação para seu modelo Xaml:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Também digno de nota, a Noesis lançou seu produto v2.0 na semana passada, e parece bastante impressionante. Seu sistema Xaml já possui extensões de marcação (em C++, com C# a caminho), e não levaram sete anos para chegar à especificação. Também é gratuito para desenvolvedores independentes agora. Depois de considerar o suporte AmmyUI , devo dizer que isso está no topo da minha lista no que diz respeito aos modelos Xaml para ATM:

http://www.noesisengine.com/

Ei @karelz talvez você possa comentar sobre isso. Mas você sabe se a "especificação" do UWP Xaml que está acontecendo agora tem alguma correlação com esse problema? Se não, sabe se pode? Ideia maluca aqui, mas pode ser bom resolver dois problemas pelo preço de um se puder ser ajudado. Eu também deixei uma mensagem lá na votação da UWP, mas imaginei que faria um ping aqui também.

@Mike-EEE UWP Xaml "spec" provavelmente é conduzido por outra organização (acho que no Windows) - pedir-lhes detalhes sobre o uservoice é provavelmente o melhor canal.

Sim, eu tinha medo disso. 😛 Recebi uma resposta lá, mas tenho que ser sincero, não faz muito sentido para mim.

Pelo que posso grok, parece que eles vão continuar a adotar uma abordagem de portas fechadas com seu processo de especificação. Isso é preocupante, pois parece que isso levaria aos mesmos resultados da última vez, terminando em uma API que ninguém quer usar ou adotar.

Talvez eles secretamente gostem de desenvolvedores reclamando de seu trabalho. :)

De qualquer forma, se você está lendo isso e é um defensor de colaboração e desenvolvimento transparente e de código aberto, e gostou de fazer parte do sucesso da iniciativa do asp/.NET Core neste domínio, por favor, reserve um segundo para para o UserVoice do WPDev e envie uma nota incentivando-os a fazer o mesmo. O link foi mencionado anteriormente, mas aqui está novamente para quem está lendo isso do e-mail:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Eu tenho que chamar @birbilis e agradecê-lo por sua contribuição anterior lá. Quaisquer palavras de confiança adicionais que alguém possa emprestar para promover o processo que todos nós usamos aqui seriam muito apreciadas. 👍

suspiro ... assim como o uservoice você faz as pessoas votarem em coisas e no final, mesmo que seja popular, não faça nada sobre isso!

Atualizar:
https://github.com/microsoft/xaml-standard

Tenho certeza que @Mike-EEE ficará muito satisfeito com isso ;P

Essa é uma grande jogada. Obrigado por compartilhar @RichiCoder1

Infelizmente, é apenas UI. Outros usos de XAML como Sharepoint e WF provavelmente estão fora.

Mas sim, pelo menos ajudará a padronizar o XAML em todas as plataformas com suporte.

Boa jogada!

Espero que eles vão dividir em camadas

Por exemplo, além da camada XAML de base não UI, gostaria de ver a camada 3D XAML

@galvesribeiro Parece que alguém criou um problema: https://github.com/Microsoft/xaml-standard/issues/23 Eu marquei +1, não há razão para o padrão eventual não ser dividido.

Tenho certeza que @Mike-EEE ficará muito satisfeito com isso ;P

Haha e você está certo, @RichiCoder1! Está tudo errado e quebrado e em nenhum lugar onde deveria estar, mas é um começo. ;) Obrigado por nos avisar. 👍

E muito satisfeito em ver alguém criando https://github.com/Microsoft/xaml-standard/issues/23 para que eu não precise. ;) ;) ;)

Por favor, considere incluir WF (Workflow Foundation) no XAML Standard!!.

@Suriman , por favor, dê um upvote!
https://github.com/Microsoft/xaml-standard/issues/23

Então, eu odeio perguntar - e eu faço isso no interesse de ser um bom cidadão de repo/issue, mas esse problema é mais necessário? Quero dizer, esse repositório já está registrando mais de 50 problemas que estão entrando em MUITO mais detalhes do que esse problema pode. Parece que já tem vida própria!

Existe uma razão para manter esta questão aqui aberta? A menos que eu esteja entendendo algo totalmente errado (bastante possível), acho que cumprimos o objetivo aqui com o Xaml Standard. É dirigido pela comunidade e tudo, o que é mais importante para mim, pessoalmente. :)

@Mike-EEE Há uma diferença sutil entre os dois problemas; o primeiro me parece ser sobre a padronização das APIs disponíveis no próprio XAML (estritamente no próprio XAML), e o outro é sobre o suporte a XAML como um componente .NET Standard semelhante ao System.Xaml.

@lokitoth definitivamente aberto à conversa sobre isso, pois ainda estou tentando grocar todas as novas peças. Suponho que seja melhor começar sugerindo assistir ao vídeo excelente e informativo de @terrajobst que demonstra o código "apenas funcionando" com o novo .NET Standard2.0. Pessoalmente, não entendi como isso afeta o System.Xaml. Meu pensamento era que deveria "simplesmente funcionar", mas talvez eu esteja começando a pensar que agora estou enganado aqui (bom demais para ser verdade).

E para ser honesto, depois de ler alguns desses tópicos no repositório Xaml Standard, eu estava meio que me chutando pela minha sugestão anterior (☕️ o café me fez fazer isso, eu juro! ☕️). Pelo que parece, "Xaml Standard" é melhor nomeado como "MSFT UX/UI Standard", pois é isso que está sendo discutido principalmente nesse repositório. Do jeito que está, o Xaml como uma poderosa tecnologia de serialização não está sendo apresentado/exibido/destacado (fora das poucas vozes corajosas aqui que fizeram os esforços lá), o que também está levando a alguma desconexão/confusão também.

Pessoalmente, não entendi como isso afeta o System.Xaml.

Precisaríamos inspecionar o assembly para descobrir se sua árvore de dependência é carregável em um contexto .NET Standard 2.0. Se for .NET puro, provavelmente funcionará (embora haja todo um conjunto de itens em tempo de compilação, por exemplo, BAML, recursos incorporados etc., que seriam trazidos para a cadeia de ferramentas do .NET Core)

Pelo que parece, "Xaml Standard" é melhor nomeado como "MSFT UX/UI Standard", pois é isso que está sendo discutido principalmente nesse repositório.

Isso, eu acho, é mais uma função de ser anunciado no contexto do UWP/Xamarin.Forms, o que significa que os desenvolvedores focados nessas duas plataformas - que podem não ter tido exposição ao "BigXaml" - são os principais contribuintes. Embora você veja alguns problemas "traga todos os dialetos WPF XAML" abertos.

Dado que há muita limpeza para a equipe fazer, e que agora a taxa de novos problemas é bastante alta em relação ao número de pessoas contribuindo, eu daria mais algum tempo para ver onde a equipe leva.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
Eu criei um problema no Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

Obrigado pelo aviso e contribuição para a conversa, @juepiezhongren!

bem @lokitoth , fico feliz por termos mantido esse problema intacto, pois foi decidido que https://github.com/Microsoft/xaml-standard/issues/23 não era adequado para a luz do dia.

No entanto, criei um novo problema que acho que faz um trabalho melhor descrevendo o problema em questão e seria incrível ter seu voto positivo e/ou contribuições adicionadas aqui: https://github.com/Microsoft/xaml-standard /questões/145

Para esclarecer, o que você está procurando seria, na verdade, artefatos gerados por _JavaScript_+HTML5+CSS3. O TypeScript é na verdade um transpilador para JS. Em vez de fazer um transpilador .NET para produzir JS compatível com os padrões que efetivamente executaria em um navegador (como JSIL ), a MSFT decidiu gastar o precioso tempo do criador do C# para fazer algo que efetivamente concorresse com ele.

Eu diria para não começar com isso, mas acho que nunca parei. 😛

Além disso, outro ponto é que CSHTML5 está muito próximo do que você está procurando @weitzhandler , mas não permite código compartilhado entre assemblies cliente/servidor (como PCLs, etc). Então você ainda acaba com duas bases de código separadas e incompatíveis para manter, resultando no mesmo problema de custo/negócio entre .NET e JS (ou TypeScript 😉) que, digamos, não existe em uma solução estritamente NodeJS.

Meu sonho é usar o estilo de escrita de interface do usuário xml do Android para aplicativos de desktop com dot net core! sim com certeza!!

Qualquer esforço para portar XAML para .NET core estou disposto a oferecer.

Em minhas modificações no CoreWf (WorkflowFoundation no padrão de rede 2.0), vejo que System.Xaml ou uma implementação Portable.Xaml mais compatível provavelmente será necessária para permitir o carregamento de DynamicActivity de Xaml . Eu tenho CoreWf rodando no framework .net com carregamento básico de DynamicActivity usando System.Xaml, mas ainda falhando devido ao estado de análise inválido no núcleo .net com Portable.Xaml.

Uma pergunta é por que o código para System.Xaml não foi adicionado ao repositório de fontes de referência licenciada do Mit? Existe um licenciamento, patente ou outro problema? Se não houver nenhum problema, adicionar esse código à fonte de referência permitiria que nós, a comunidade, fizéssemos a portabilidade necessária para dar suporte ao CoreWf. O repositório de origem de referência não compromete a Microsoft a oferecer suporte ao System.Xaml. Devo adicionar um problema solicitando que o System.Xaml seja aberto?

Se System.Xaml não for aberto, podemos ter um documento (além da especificação Xaml) ou suporte na forma de testes que descrevem as etapas corretas para analisar e tokenizar o código Xaml para WorkflowFoundation?

Ei, FWIW @karelz , eu coloquei alguns pensamentos sobre o cenário DevOps aqui:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Com base em alguns acontecimentos interessantes no Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Pensei em mencionar isso aqui, enquanto eu estava nisso. 👍 Além disso, este tópico está atrasado para um solavanco. 😆

@weitzhandler você precisa ser atualizado, pois o mono-wasm está no caminho alfa, está quase na hora de começar a esquecer o js.

@weitzhandler 2 ou 3 anos são necessários, mas não é apenas uma pilha completa, é uma pilha universal para .net.

CoreRT também está a bordo - https://github.com/dotnet/coret/pull/4480 . Esperando por um combo HTML+CSS+C# pronto para produção no próximo ano.

O pacote de compatibilidade .net proposto inclui System.Xaml com status talvez e vinculado a este problema.

Aparentemente, esse problema foi vinculado ao compat pack 2.1? Alguém pode confirmar? Vejo que foi marcado netfx-compat-pack, mas não com uma versão. Eu vou tomar isso sobre qualquer coisa que tenha ocorrido até agora, no entanto. 😄

Odeio decepcionar, mas acho que acidentalmente marquei isso como 2.1 quando estava atualizando em massa os problemas do pacote comapt. Mudei para o Futuro para refletir o status de talvez na proposta.

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

Obrigado pela atualização senhores. Aprecio você pensando em mim. :) @terrajobst isso é realmente decepcionante, mas agradeço que você reserve um tempo para fazer o check-in e atualizar. Eu não tinha certeza se você ainda estava inscrito neste tópico ou não. 👼

Como estamos gastando tempo para conectar projetos descaradamente (e que levará algum tempo até obtermos nossa correção oficial do Xaml), vou tirar um segundo para mencionar que passei o ano passado ajudando com a v2 do ExtendedXmlSerializer , que foi lançado recentemente. Ele apresenta suporte experimental para extensões de marcação e propriedades anexadas (que funcionam em POCO, não é necessário DependencyObject ) e também serialização parametrizada no estilo protobuf .

Se você estiver procurando (ou adicionar) funcionalidade Xaml-ish enquanto aguardamos a chegada do System.Xaml, sinta-se à vontade para verificar, fornecer feedback ou (melhor ainda) enviar um PR no repositório. 👍

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

@danmosemsft o xaml do Workflow Foundation será suportado em projetos SDK como parte da iniciativa de desktop 3.0?

@lokki não conheço planos. @terrajobst @karelz?

@danmosemsft
Por que não há um problema que diz "Fornecer uma estrutura de interface do usuário como parte do .NET Core"?

Este problema não fala especificamente sobre a falta de uma estrutura de interface do usuário, e parece que as pessoas aqui não percebem isso.
Veja isto: https://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler Esta questão faz MUITO mais sentido para mim agora. Obrigado pelo esclarecimento.

Posso ver System.Xaml incluído no .NET Standard sendo útil, principalmente junto com o XAML Standard.

se eu entendi corretamente a "iniciativa de desktop", você deve poder usar bibliotecas .NET que você poderia usar no passado, desde que você segmente apenas o Windows (não tenho certeza se seu aplicativo será capaz de se adaptar dinamicamente ao ambiente em que executado, se o aplicativo principal não for capaz de fazê-lo [por exemplo, não iniciaria se não encontrar o sistema operacional Windows], provavelmente você poderia fazer isso criando vários assemblies .NET Core que chamam as coisas específicas da plataforma e carregá-los sob demanda, dependendo da plataforma em que o aplicativo detecta que está sendo executado)

@birbilis não é suficiente. O mesmo XAML precisa renderizar igualmente em todas as plataformas.

A iniciativa de desktop não é sobre XAML, é sobre o .NET Core não ser um silo de mínimo denominador comum, mas sim permitir aplicativos que podem direcionar plataformas específicas (ou, idealmente, também se adaptar dinamicamente à plataforma em que estão sendo executados) e tornar o melhor usá-los, fazer integrações específicas de plataforma etc. Pode-se construir APIs baseadas em capacidade em cima dessa funcionalidade para que os aplicativos possam ser escritos que apenas consultam a disponibilidade de um recurso específico. Também APIs de abstração/compatibilidade podem ser construídas sobre isso, conectando-se a diferentes implementações para cada plataforma que os autores de uma API estão interessados ​​em dar suporte.

Por enquanto, eu acho, Portable.Xaml está tão perto do System.Xaml agora. Se você encontrar algum problema, por favor, dê feedback.

A equipe do WPF (@dotnet/wpf-developers ) acaba de anunciar o código aberto do WPF para .NET Core 3.0. Como parte disso, as compilações de visualização do .NET Core 3.0 agora contêm System.Xaml e as fontes correspondentes estão disponíveis em https://www.github.com/dotnet/wpf.

por falar nisso