Runtime: O futuro do JSON no .NET Core 3.0

Isso é ótimo. Eu sou totalmente a favor da análise json mais rápida e menos alocada.

Haverá uma discussão sobre os recursos do json.net que o novo json apis oferecerá suporte? Se houver, acho que os dois principais recursos que vêm à mente seriam renomear / propriedades de maiúsculas e minúsculas e ignorar propriedades nulas.

Haverá uma discussão sobre os recursos do json.net que o novo json apis oferecerá suporte?

sim. Pensamos desde o início que iremos migrar para o CoreFx. Será um recurso projetado e construído ao ar livre, como de costume. Além disso, entrei em contato com autores de muitas das bibliotecas JSON populares e os convidei para revisar os primeiros rascunhos deste anúncio. Minha esperança é que possamos trabalhar juntos para criar um componente JSON sólido para a plataforma e, ao mesmo tempo, manter o ecossistema em cima dele (como ASP.NET Core) conectável para permitir que outros. No final, diferentes consumidores terão objetivos diferentes e poder plug-in em uma biblioteca diferente significa que você pode obter o máximo de flexibilidade na escolha do componente que tem o melhor custo / benefício para seu aplicativo.

Ei @terrajobst. O novo JSON aparecerá como uma superfície de API padrão da rede ou apenas integrado ao Core por enquanto?

Ei @terrajobst. O novo JSON aparecerá como uma superfície de API padrão da rede ou apenas integrado ao Core por enquanto?

Sim, a questão é qual trem de liberação ele pode pegar. 2.1 pode ser muito cedo.

Portanto, os bits de análise JSON embutidos na estrutura estão planejados para estarem disponíveis quando a v3.0 for para RTM ou apenas a integração Apis no ASP.NET Core será concluída (com apenas uma implementação - JSON.NET) que será trocável em um data posterior?

O plano para 3.0 é o seguinte:

1. APIs JSON de alto desempenho integradas. Leitor / gravador de baixo nível, um leitor / gravador baseado em Stream e um serializador.
2. O ASP.NET Core pode ser conectado ao componente JSON.

Há uma questão em aberto sobre o que os modelos para ASP.NET 3.0 usarão. Dependendo fidelidade, podemos fornecer 3,0 poderíamos tê-los puxar o pacote de integração Json.NET. No entanto, o objetivo é fornecer fidelidade e paridade suficientes para depender apenas dos integrados por padrão.

Obrigado - isso ajuda a esclarecer as coisas. 👍

E algumas perguntas adicionais!

Se um pacote de integração for usado, ele será usado em todo o pipeline do ASP.NET Core ou apenas em alguns lugares?
Estou assumindo que Kestrel sempre usará os leitores / escritores internos.

A ergonomia do Api seria:

• Forneça uma integração apenas quando desejar aprimorar o conjunto de recursos internos.
• Forneça um pacote de integração sempre, mas um seria embutido, integrando o leitor / gravador de baixo nível em uma funcionalidade de alto nível.

Supondo que esse novo analisador seja usado para todas as coisas JSON embutidas, como appSettings.json , eu poderia fazer uma solicitação antecipada de suporte para comentários?

Obrigado.

Esta é uma notícia incrível! Pergunta rápida: de quais pacotes essa biblioteca dependerá?

Por que reinventar uma roda que é testada por clientes de produção? Se houver algum problema com o Json.Net, basta enviar um PR, pois ele é de código aberto.

Suponho que o problema com o Json.NET é que ele não é propriedade da Microsoft, então ele precisa ser substituído. Ah, mas já existe aquele em System.Runtime.Serialization, chamado DataContractJsonSerializer. Você pode usar isso ou é tão divertido codificar novas APIs, DIY, que não pode ser evitado?

O motivo pelo qual não estou muito feliz com isso é que o Json.Net suporta casos já extremos como, por exemplo, Uniões Discriminadas F #. Não muito bem, mas em um nível em que os desenvolvedores podem conviver com isso. Em vez disso, qualquer nova API geralmente esquece qualquer outra coisa senão o caso de uso de um site ASP.NET.

@markrendle Existe uma configuração de aceitação no JsonReader (trabalho em andamento) para permitir comentários. O sistema de configuração provavelmente habilitará essa configuração por padrão.

@Thorium Você realmente leu o OP? Isso explica por que não JSON.NET e que JSON.NET continuará a ter suporte oficial com um pacote de suplemento.

@JamesNK 😄

@Thorium Json.NET não vai desaparecer. Você não está perdendo nada. Esta é outra opção para cenários simples e de alto desempenho.

@Thorium Json.NET não vai desaparecer. Você não está perdendo nada. Esta é outra opção para cenários simples e de alto desempenho.

Como o Json gerado será compatível com versões anteriores?

Por exemplo, estou usando SignalR, que usa Json.NET em segundo plano. Agora, minhas uniões discriminadas F # serão serializadas em estruturas semelhantes para que eu não esteja lutando contra problemas com o novo Azure Signalr Service (backplane), lançando exceções de tempo de execução devido à serialização das estruturas de forma diferente da biblioteca SignalR atual do meu servidor?

Espero que outros aprendam as novas APIs rapidamente. Olhando para você, @AzureCosmosDB ;-)

Você está planejando incluir uma classe como JObject e suporte para dinâmica ou isso está fora do escopo para este recurso?

Eu recomendo uma olhada em uma destas bibliotecas:

• https://github.com/kevin-montrose/Jil ou
• https://github.com/neuecc/Utf8Json

esta pode ser uma boa forma de obter inspiração.

Será que DataContractJsonSerializer este novo leitor / escritor será usado internamente?

Procurei autores de muitas das bibliotecas JSON populares e os convidei para revisar os primeiros rascunhos deste anúncio. Minha esperança é que possamos trabalhar juntos para criar um componente JSON sólido para a plataforma e, ao mesmo tempo, manter o ecossistema em cima dele (como ASP.NET Core) conectável para permitir que outros.

Existe uma razão pela qual a 2ª biblioteca JSON mais popular depois de JSON.NET - ServiceStack.Text que já foi refatorada para ser construída no SpanAPIs foi excluído? Serializadores ServiceStack.Text são usados ​​para alimentar o ServiceStack, um dos mais populares "Framework da Web compatível com o .NET Core alternativo" que oferece suporte à execução em mais plataformas em .NET . Estou curioso para saber a qual "ecossistema" você está se referindo e com o qual espera "trabalhar junto" aqui? Obviamente, eu estaria interessado em saber o quão compatíveis essas APIs "plugáveis" acabam sendo ou se isso acaba sendo outra área em que a adoção e integração de novas bibliotecas MS acaba matando o ecossistema que está substituindo.

Pode valer a pena revisar o MIT licenciado de alto desempenho https://github.com/neuecc/Utf8Json

Definitivamente é disso que precisamos ... minha sugestão para o nome da classe principal, basta usar " Json ".

@terrajobst , estava me perguntando quando isso aconteceria ...

Sempre me perguntei por que JSON.Net foi adicionado como uma dependência direta ao invés de uma abstração (mesmo considerando que é o pacote JSON de fato para o ecossistema .Net).

No entanto, acho que adicionar uma abstração apenas para JSON é, de alguma forma, um tiro no pé. Acho que uma abstração _serializer_ como a que temos em Orleans IExternalSerializer no formato Microsoft.Extensions.Serialization ou algo assim seria mais eficaz ...

Existe algum motivo específico para o make ser somente JSON? Vejo outros casos em que as pessoas podem conectar outros tipos de serializadores ...

@galvesribeiro Algo como IOutputFormatter / IInputFormatter ?

@ yaakov-h não estava ciente deles ... Eles estavam?

@galvesribeiro AspNetCore: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.formatters.iinputformatter?view=aspnetcore-2.1

Ok ... faz sentido agora. Então, onde essas _novas_ abstrações somente JSON entram em cena?

A decisão de iniciar este empreendimento também é uma prova da ineficiência de System.String (UTF-16 String).
Acho que os novos ganchos JSON que abstrairão todo o manuseio de json entre asp.net e uma biblioteca de json pareceriam significativamente melhores se você abordasse a tarefa de criar uma string utf-8 BaseType primeiro.
-> Talvez crie um System.Utf8String

Sim ... eu me lembro de @migueldeicaza dizer um tempo atrás que um dia ele faria .Net usar utf8 strings 😄

@ jges42 @galvesribeiro A proposta para adicionar Utf8String é https://github.com/dotnet/corefx/issues/30503. Parece que também está planejado para .Net Core 3.0.

Essas novas APIs JSON terão caminhos de código dedicados para Utf8String e char / string ou a otimização envolve inverter o status quo, de modo que tudo que não é UTF-8 terá que ser transcodificado para ele em vez disso? (Isso não envolve necessariamente um custo enorme, já que quase nada é string o UCS-2 UTF-16 nativo e ainda precisa ser adaptado / contabilizado, estou apenas tentando ter uma ideia do Superfície da API. Fazer isso para deixar o Kestrel mais eficiente é razoável; só espero que o design considere mais clientes do que o Kestrel.)

@galvesribeiro
Na verdade, acho que você levantou um bom ponto. Acho que criar uma estrutura de serialização eficiente e um decodificador / codificador Json eficiente são dois tipos de problemas. Eu sei que existem algumas maneiras de marcar uma estrutura como serializável, mas nunca vi isso ser usado para qualquer serialização Json.

O projeto Serde da Rust tem, na verdade, um bom conceito, dividindo o problema em 2 problemas:

1. Serializar / desserializar (características semelhantes às interfaces em C #), o que significa que qualquer tipo que herde dessa interface pode ser serializado / desserializado
2. Serializer / Deserializer é a implementação específica do formato.

Um tipo pode implementar Serializar / Deserializar manualmente ou por meio de uma macro (que pode ser vista como uma forma de plug-in do compilador) que gera o código necessário para executar a implementação dessas Características. Se um tipo contém um tipo filho que não implementa essas características, ele até avisará em tempo de compilação. É um bom conceito geral porque significa que você pode simplesmente escrever alguns objetos de dados e (des) serializar para qualquer formato suportado. Escrever um formato é muito mais fácil dessa maneira.

Eu não acho que todos os métodos de Serde funcionarão para C # porque ele realmente não oferece nenhum atributo específico de tipo que poderia ser importante para algumas estruturas de dados. Portanto, deve haver algum trabalho feito para isso. Também considerar a compilação AoT será muito importante para alguns projetos (WASM). Ela também deve funcionar bem com ela.

Aqui está um link para os documentos do Serde para torná-lo mais claro (clique nas 4 características inferiores para ver o conceito):
https://docs.serde.rs

@mythz A licença de ServiceStack.Text é AGPL com algumas exceções FOSS - provavelmente impediria as pessoas de usá-la em software proprietário. Além disso, acho que exige autorização legal para os funcionários da Microsoft até mesmo tocá-lo, e qualquer funcionário que tenha consultado a fonte pode ser impedido de trabalhar em qualquer outra biblioteca JSON ou tecnologia relacionada.

@ poizan42 ServiceStack.Text tem licença dupla com licenças OSS / comerciais gratuitas para uso em projetos comerciais de software livre e de código fechado. Mas as licenças do código-fonte são irrelevantes, pois a MS está desenvolvendo sua própria implementação.

A afirmação era de que a MS estava colaborando com o "ecossistema" para desenvolver APIs serializadores JSON "plugáveis" - se o ServiceStack, que está em desenvolvimento ativo há quase uma década, é um dos poucos pacotes independentes de software .NET que conseguiu sustentar sua própria comunidade saudável independente fora do MS durante sua vida, que mantém o segundo serializador JSON mais popular depois do JSON.NET e o que parece ser o segundo Web Framework mais popular desenvolvido ativamente (fora do MS), que roda em mais plataformas do que qualquer MS web framework não é considerado parte do "ecossistema" que é principalmente afetado por essas mudanças. Estou curioso para saber a que "ecossistema" eles se referem e por que estamos sendo excluídos e quantos outros estão sendo excluídos porque estão não é considerado parte do "ecossistema".

Não entendo todo esse ressentimento. Asp.net forçou você a usar uma versão específica do json.net. Eles estão mudando para que você possa escolher o analisador JSON que quiser (ou misturá-lo), e há um OOB padrão. A ServiceStack deve ficar feliz com essa mudança e monitorar e fornecer feedback sobre esse desenvolvimento, em vez de apenas reclamar de como isso foi esquecido, o que raramente é uma maneira eficaz de fomentar um bom espírito de comunidade. Eu pessoalmente conheço muitos dos membros da equipe .net e estou confiante de que eles não tiveram nenhuma intenção de malícia. Todos eles são grandes defensores do OSS e do trabalho comunitário.
Pessoalmente, qualquer licença derivada da GPL seria um grande não automático para mim. Apache ou MIT para mim e meus clientes ou seguiremos em frente. Sem licenças duplas misteriosas.

Asp.net forçou você a usar uma versão específica do json.net

Não. Como assim?

Não entendo todo esse ressentimento.

Destacado!

Estou pessoalmente feliz que finalmente seremos capazes de usar o serializador de nossa escolha sem ter que baixar JSON.Net apenas para não usá-lo, mas ainda precisa enviá-lo porque ASP.Net tem uma referência difícil para a biblioteca.

(Plugue sem vergonha: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

Não entendo todo esse ressentimento.

Porque você não leu nem entendeu meus comentários. Tente responder diretamente aos meus comentários (ou seja, use o recurso de citação) em vez de inventar sua própria narrativa.

Eles estão mudando para que você possa escolher o analisador JSON que desejar (ou misturá-lo)

Assim, como uma "mistura" mágica, eles escolherão automaticamente as opções mais ideais de API e plugabilidade que os serializadores .NET existentes serão capazes de conectar / desconectar e misturar em suas opções de personalização internas com o formato de fio sendo exatamente o mesmo e tudo vai funcionar em todos os serializadores? Nesse caso, você está certo, nenhum teste de colaboração ou integração é necessário antes que as APIs sejam solidificadas. Ou talvez as implementações do Serializer tenham mais nuances com várias diferenças e opiniões e tudo não vai funcionar, nem todas as opções de personalização serão implementadas exatamente, o formato do fio não será o mesmo e não será possível alcançar interoperabilidade perfeita entre diferentes implementações. A "plugabilidade" que você está encobrindo faz uma grande diferença, que pode determinar o quanto de uma reescrita teremos que fazer e se será ou não possível dar suporte à implementação existente e a esta nova.

ServiceStack deve ficar feliz com esta mudança e monitorar e fornecer feedback sobre este desenvolvimento,

O que não tivemos oportunidade de fazer (ou ainda sabemos fazer), mas obrigado por me dizer como eu deveria me sentir. Eu prefiro avaliar a funcionalidade, interoperabilidade e compatibilidade da biblioteca antes de poder avaliar a força de cada uma. Talvez seja ótimo e seja fácil oferecer suporte a ambas as implementações, mas com base na experiência, a interoperação com diferentes implementações de serializador é repleta de incompatibilidades e casos extremos e dependência de diferentes implementações e recursos específicos de serialização. Minha previsão é que a interoperabilidade entre JSON.NET e o impl padrão será ótima, uma vez que esse é o objetivo do design e o que está sendo testado, mas outros serializadores não serão tão afortunados.

em vez de apenas reclamar de como isso foi esquecido, o que raramente é uma forma eficaz de fomentar um bom espírito de comunidade.

Desafio a afirmação deles de que desenvolveram isso em colaboração com o "ecossistema". O .NET tem uma história de matar o ecossistema existente cada vez que empacota uma biblioteca "padrão", o que também espero que aconteça aqui (estou lutando para me lembrar de uma época em que agrupar um padrão já ajudou o ecossistema). Mas, independentemente disso, precisamos desenvolver uma integração perfeita com tudo o que eles estão lançando e que eu gostaria de ter acesso e entrada antes que as APIs sejam congeladas. Mas tudo bem, eu não espero que você se importe como isso afeta os frameworks / bibliotecas existentes que precisam dar suporte a implementações existentes e futuras, você provavelmente só se preocupará se o JSON.NET permanecer com suporte ou não, porque isso é tudo que afeta você, mas tente manter suas suposições e nos dizer como devemos nos sentir sobre a absorção de mudanças perturbadoras como essa.

estou lutando para me lembrar de uma época em que agrupar um padrão já ajudou o ecossistema

Oh vamos lá!

(No resto, concordo principalmente com seus sentimentos)

@mythz Estou surpreso que isso esteja causando problemas, já que hoje agrupamos outra biblioteca JSON de terceiros no framework. Existem apenas alguns lugares onde preparamos JSON e a maioria deles tem um modelo de provedor que os usuários poderiam substituir razoavelmente (como formatadores MVC).

Minha previsão é que a interoperabilidade entre JSON.NET e o impl padrão será ótima, uma vez que esse é o objetivo do design e o que está sendo testado, mas outros serializadores não serão tão afortunados.

Já posso dizer que o que enviaremos não oferecerá suporte à gama de recursos que o JSON.NET oferece. Portanto, isso já não é verdade e, de fato, esperamos que seja menos capaz em alguns casos (por causa de desempenho e escopo).

A conectividade já existe principalmente hoje e temos implementações JSON.NET padrão em todos os lugares. Isso é apenas alterar o padrão para ser o novo serializador JSON ...

@abatishchev

Eu realmente não consigo me lembrar de nenhum, quando incorporar ou adotar uma implementação padrão em sua estrutura de base (ou projetos) beneficiou o ecossistema circundante existente? Todas as vezes que o vi agrupado, por exemplo, NuGet, MVC, ORMs, Testes Unitários, API da Web, etc., só teve um efeito prejudicial, tirando o oxigênio e a motivação para competir naquele espaço.

Há momentos como em que bibliotecas concorrentes como ASP.NET Ajax não conseguiram competir onde acabaram abandonando-o e adotando o jQuery, mas não me lembro de uma época em que isso tenha ajudado? Nota: Esta é apenas minha observação ao seguir de perto o .NET depois de vários anos, talvez haja exemplos e eu estaria curioso para saber de alguns? mas, do meu ponto de vista, os efeitos dos padrões do MS têm um efeito prejudicial no ecossistema existente de funcionalidade que está substituindo.

Os benefícios do

Mas não vamos nos sobrecarregar e nos limitar ao assunto. Saúde!

@davidfowl Isso está apenas mudando o padrão para ser o novo serializador JSON ...

Gostaria de propor que não haja um serializador padrão e exigir que uma implementação seja baixada. Se deve haver um padrão, ele será incluído na estrutura ou em alguma biblioteca separada (como é o caso atualmente)?

Gostaria de propor que não haja um serializador padrão e exigir que uma implementação seja baixada. Se houver um padrão, ele será incluído na estrutura ou em alguma biblioteca separada (como é o caso atualmente)?

Isso é irracional, pois a experiência será abaixo da média. Cada plataforma moderna tem JSON integrado.

@davidfowl Não está causando problemas agora porque não foi lançado, mas ainda precisamos avaliar a interrupção e o escopo do trabalho que isso vai causar. Quanto esforço será necessário para suportá-lo perfeitamente, seremos capazes de aplicar personalizações ao novo impl para dar suporte ao nosso comportamento existente, seremos capazes de oferecer suporte ao novo modelo de personalização e APIs, seremos capazes de personalizar nosso serializador para suportar a configuração / formato de conexão padrão as novas APIs serão capazes de oferecer suporte a .NET Core e .NET Framework - embora esteja claro que o ASP.NET Core 3 abandonará o .NET Framework, não está claro se as novas APIs serão usadas. NET Core apenas tipos que nos impedirão de continuar a oferecer suporte ao .NET Core e ao .NET Framework.

Já posso dizer que o que enviaremos não oferecerá suporte à gama de recursos que o JSON.NET oferece. Portanto, isso já não é verdade e, de fato, esperamos que seja menos capaz em alguns casos (por causa de desempenho e escopo).

Só espero que ele suporte um subconjunto de recursos JSON.NET, por exemplo, o JSON.NET oferecerá suporte ao formato de fio padrão? (Presumo que sim). O novo impl adotará formatos de serialização JSON.NET sempre que possível (também presumindo que sim).

Quanto esforço será necessário para suportá-lo perfeitamente, seremos capazes de aplicar personalizações ao novo impl para suportar nosso comportamento existente, seremos capazes de oferecer suporte ao novo modelo de personalização e APIs, seremos capazes de personalizar nosso serializador para suportar a configuração / formato de conexão padrão permitirá que as novas APIs ofereçam suporte ao .NET Core e ao .NET Framework.

@mythz Não estou

@mythz, a única preocupação real que vejo para o servicestack seria se essa nova API não fosse compatível com o .net framework classic, dessa forma o servicestack não seria capaz de oferecer suporte para os pacotes .net core e .net classic, como cliente. dependendo dessas bibliotecas, não estará disponível no framework .net completo. Essa é a sua preocupação? estou perguntando porque sua preocupação como um exemplo concreto não é clara.

Além disso, esta é uma proposta em seu estágio inicial e o objetivo que pretende alcançar parece bastante promissor. A crítica construtiva é sempre boa para qualquer projeto OS.

Os benefícios do

Por ecossistema, estou me referindo ao ecossistema / comunidades da biblioteca .NET circundante (que presumivelmente também é o "ecossistema" no OP) que substitui e que eu também diria que os usuários .NET também se beneficiam de um ecossistema saudável com uma variedade de opções e mais competição (como é a característica de ecossistemas mais saudáveis ​​como Python, Java, Node, Ruby, PHP, etc).

EF é o melhor ORM do mundo .NET

Logo após o lançamento do EF, ele rapidamente consumiu a maior parte do mercado ORM, embora fosse 6x mais lento do que o NHibernate, embora suportasse menos recursos, trecho da minha entrevista do InfoQ de 2012 :

Sua última tentativa em uma camada de acesso a dados ORM no Entity Framework impactou negativamente a comunidade outrora próspera do ORM NHibernate anteriormente proeminente. Apesar de ser várias vezes mais lento do que qualquer outro ORM .NET de código aberto , o EF conseguiu atrair mais downloads do que todos os outros ORMs combinados.

Lembre-se de que isso era antes do .NET Core, onde o desempenho agora é uma prioridade, mas é um exemplo histórico do efeito prejudicial que os padrões do MS têm sobre os ecossistemas / comunidades existentes. IMO, é bastante aceito o que acontece com as comunidades existentes quando o MS apresenta padrões, e é por isso que houve um retrocesso recente para reverter os padrões de envio que competem com IdentityServer e AutoMapper.

e o MSTest era melhor do que o NUnit naquela época.

IMO nunca foi (e o suporte R # de NUnit sempre foi excelente AFAICR) e o fato de não podermos executá-lo em plataforma cruzada no Mono significava que as bibliotecas que suportavam plataforma cruzada no Mono (antes do .NET Core) não podiam usar isto.

Mas não vamos nos sobrecarregar e nos limitar ao assunto. Saúde!

Eu também não quero sequestrar este tópico sobre isso, mas preciso declarar por que discordo de seus pontos.

Em relação a isso, o principal motivo agora para usar um serializador diferente do JSON.NET é o desempenho e, dado o motivo para esse novo serializador padrão, é o desempenho. Como a maioria das pessoas apenas usa padrões, espero que isso tenha o impacto mais perceptível no compartilhamento JSON.NET, enquanto o motivo principal para usar um serializador alternativo não deve mais existir com este impl mais rápido. Basicamente, também vejo que isso tem um efeito prejudicial no ecossistema (biblioteca) existente. IMO, um ecossistema mais fraco de libs JSON é uma rede negativa para .NET (não é algo que a maioria dos consumidores verá, pois apenas usarão os padrões e esquecerão as outras opções), mas essa não é minha principal preocupação.

@davidfowl @ shahid-pk

Apesar disso, eu teria preferido que isso existisse há 8 anos, pois o principal motivo para o desenvolvimento do ServiceStack.Text foi porque os serializadores JSON do .NET Framework eram extremamente lentos. Mas depois de todo esse tempo, SS.Text foi estendido com uma série de recursos em todas as nossas bibliotecas, por exemplo, personalizações para oferecer suporte a diferentes idiomas ServiceStack Suporta , diferentes opções de personalização JSON em ServiceStack , suporte JSON em modelos ServiceStack , suporte a blob JSON de tipo complexo em ServiceStack .Redis etc.

Portanto, agora estou focado em avaliar qual será o impacto, como serão as novas opções de API e plugabilidade, podemos readaptar recursos existentes nela, seremos capazes de adotar como o serializador JSON em aplicativos SS .NET Core (o que vai quebrar), ServiceStack.Text será capaz de suportar a nova API, seremos capazes de suportar .NET v4.5, será capaz de personalizá-lo para suportar formatos de cabo de implantações existentes, etc. I Basicamente, não tenho ideia de qualquer impacto sobre isso ou de qual estratégia terá no futuro, pois ainda não tive a chance de usar ou ver nada. Eu saberei mais respostas quando tiver a chance de usá-lo e obviamente gostaria de ter a oportunidade de testar a integração e fornecer feedback e propor mudanças antes que as APIs sejam congeladas.

@mythz

Existe uma razão pela qual a segunda biblioteca JSON mais popular depois de JSON.NET - ServiceStack.Text, que já foi refatorada para ser construída em APIs Span , foi excluída?

A omissão não foi intencional. Pesquisamos e trabalhamos ativamente com os autores da biblioteca JSON como parte do repositório CoreFxLab e um de nossos desenvolvedores começou a comparar nossos trabalhos com os deles. Acredito que a lista foi inicialmente preenchida usando termos de pesquisa básicos como "json" no NuGet . Parece que sua biblioteca simplesmente não apareceu. Eu entendo que isso pode ser frustrante ou preocupante para você, mas tente entender a situação do nosso lado: não se pode esperar que nossa equipe conheça todas as bibliotecas existentes. Este anúncio faz parte do nosso modelo de desenvolvimento aberto para envolver toda a comunidade. A única razão pela qual tendemos a alcançar grupos menores primeiro é garantir que nossos planos e mensagens tenham um nível razoável de consideração e qualidade antes de compartilhá-los com o mundo. Nada é definitivo ainda. Estamos procurando ativamente por feedback adicional.

Estou curioso para saber a qual "ecossistema" você está se referindo e com o qual espera "trabalhar junto" aqui?

O ecossistema .NET e em particular as partes interessadas no processamento JSON.

Obviamente, eu estaria interessado em saber o quão compatíveis essas APIs "plugáveis" acabam sendo ou se isso acaba sendo outra área em que a adoção e integração de novas bibliotecas MS acaba matando o ecossistema que está substituindo.

O objetivo dos pontos de extensão planejados do ASP.NET Core é permitir que os clientes substituam o componente JSON integrado por qualquer biblioteca JSON que desejarem. Obviamente, o ASP.NET sempre foi fornecido com "baterias incluídas", ou seja, uma experiência padrão razoável. No passado, isso era Json.NET e, no futuro, é um componente fornecido pela plataforma. Dado que o Json.NET foi um pouco conectado ao ASP.NET, o novo plano parece melhor em termos de rede para pessoas como você; portanto, não tenho certeza de qual parte de nosso plano você acha que é uma ameaça.

Há uma questão em aberto sobre o que os modelos para ASP.NET 3.0 usarão.

Não é hora de os modelos serem modulares? Como vue.js, por exemplo.

A criação de um novo aplicativo vue permite que você escolha o que deseja. Por que algo semelhante não pode ser feito para asp.net em vez de criar 500 modelos para atender a todos os cenários.

Aqui está um exemplo concreto de um recurso em .ASP NET Core 2.2 em que formatadores de entrada / saída JSON não JSON.NET enfrentarão problemas e como uma solução desacoplada pode ajudar:
O recurso ProblemDetails , que permite uma resposta de erro compatível com RFC 7807 :
https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ProblemDetails.cs

[JsonProperty(NullValueHandling = NullValueHandling.Ignore, PropertyName = "instance")]
public string Instance { get; set; }

[JsonExtensionData]
public IDictionary<string, object> Extensions { get; } = new Dictionary<string, object>(StringComparer.Ordinal);

O código acima é anotado com atributos específicos de JSON.NET, incluindo um atributo de fallback específico [JsonExtensionData] , todas as propriedades JSON desconhecidas são desserializadas neste dicionário e o conteúdo deste dicionário é serializado na estrutura JSON normal.

Qualquer formatador de entrada / saída JSON alternativo agora precisa lidar com esses atributos específicos do JSON.NET para ser capaz de serializar / desserializar adequadamente este tipo ou encontrar uma maneira diferente, ou seja, fallback para JSON.NET para esses tipos.

Agora, se tivermos uma especificação bem definida de recursos que um Input / OutputFormatter para JSON precisa suportar para 3.0, o problema acima não existe, ou seja, esses atributos poderiam estar em um pacote Microsoft.Extension ... e em cada Formatador JSON personalizado poderia usá-los para implementar esta funcionalidade para ser compatível.

Pelo que sei, existem apenas algumas instâncias de código-fonte "oficial" no ASP.NET Core que são anotados por atributos JSON.NET, mas também vi bibliotecas de terceiros usando atributos específicos de JSON.NET (geralmente para especificar o nome do atributo por meio de [JsonProperty("name")]

FWIW, é disso que se trata https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Acho que você respondeu antes de ler meu comentário anterior, que a IMO esclarece mais minhas preocupações.

Estamos procurando ativamente por feedback adicional.

Onde? Existe uma proposta / documento de API, uma API foi criada, sob qual repositório ela está sendo desenvolvida?

Acho que você respondeu antes de ler meu comentário anterior, que a IMO esclarece mais minhas preocupações.

Eu li, mas parece que você se opõe a qualquer padrão, o que, como @davidfowl explicou, não é prático para nós. Meu ponto é que nosso plano é uma melhoria do que temos atualmente, ou seja, um hardware de fato para Json.NET. Daí minha pergunta.

Onde? Existe uma proposta / documento de API, uma API foi criada, sob qual repositório ela está sendo desenvolvida?

Deliberadamente, ainda não fizemos nenhum projeto de codificação / API no .NET Core porque queríamos fazer este anúncio primeiro. Não queríamos que as pessoas lessem as folhas de chá sem fornecer o contexto fornecido por este anúncio. Em outras palavras, fique ligado, publicaremos APIs e código em breve.

@terrajobst Impressão completa para postar isso

1. A decisão de fazer alterações está tomada.

No futuro, planejamos fazer algumas alterações em nosso suporte JSON:

1. Algum projeto preliminar é feito
   Precisamos de APIs JSON de alto desempenho.
   Remova a dependência do ASP.NET Core para Json.NET.
   Fornece um pacote de integração ASP.NET Core para Json.NET.

Tudo isso significa que a direção é tomada. Tudo o que se pede ao "ecossistema" é encontrar pontos de dor óbvios que a MS não poderia explicar de forma realista.

Omissão de ServiceStack e discuti-lo como uma biblioteca .NET de classe secundária é ridículo. Mesmo eu apenas em bibliotecas MS distribuídas, isso não significa que eu não saiba sobre alternativas.

Não estou tendo problemas com a tomada de decisões do MS, mas se isso foi declarado diretamente e não foi abordado com "feedback da comunidade" sobre as decisões já tomadas.

Essa é a minha impressão

@terrajobst

Eu li, mas parece que você se opõe a qualquer padrão

Nunca sugeriu isso, JSON.NET já era o padrão antes disso. Eu expliquei com mais detalhes acima, mas para reiterar, isso está posicionado para assumir o padrão e se tornar o novo padrão de fato, onde efetivamente o .NET Core terá apenas 2 serializadores JSON em seu futuro: este novo padrão de alto desempenho de fato e JSON. NET para recursos personalizados. Outros serializadores JSON se tornarão um nicho, por exemplo, recursos exclusivos adicionados para oferecer suporte a diferentes cenários.

Deliberadamente, não fizemos nenhum projeto de codificação / API no .NET Core porque queríamos receber este anúncio primeiro.

Ok, então não é possível para nenhum "estranho" saber quão bem a plugabilidade, extensibilidade ou interoperabilidade
será ainda.

Não queríamos que as pessoas lessem as folhas de chá sem fornecer o contexto fornecido por este anúncio. Em outras palavras, fique ligado, publicaremos APIs e código em breve.

Então foi desenvolvido internamente? Quanto tempo depois de seu lançamento, os estranhos terão que testar e propor mudanças no design da API? Minha principal preocupação com a aparência das APIs "plugáveis" e "extensíveis": seremos capazes de "assumir o controle" e ter controle total para o formato de fio dos Tipos de referência / valor? E quanto aos tipos integrados, Enums, bools, outros intrínsecos, etc? Por exemplo, ele será capaz de configurar bool para aceitar outros valores JSON populares como "sim", "on", "1".

Outras perguntas:

• Essa implementação pode ser usada autônoma (em um pacote NuGet separado)?
• É a parte "plugável" da API ligada ao Web Framework ou pode ser usada em outro lugar (por exemplo, Xamarin / UWP)
• Ele será compatível com .NET Standard 2.0 ou .NET v4.5?
• Caso contrário, as APIs serão capazes de suportar .NET Standard 2.0 ou .NET v4.5?

@mythz
Não é realmente desenvolvido internamente (pelo meu conhecimento), a parte Leitor / Escritor é feita em corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) e, especificamente, não há API de alto nível para ele ainda no corefxlab.

Pessoalmente, eu exceto que as partes extensíveis / plugáveis ​​da API sejam .NET Standard (ou seja, atributos etc.). A biblioteca no corefxlab é o .NET Standard 1.1 no momento, mas imagino que isso vai mudar dependendo dos objetivos de desempenho da biblioteca, etc.

@mythz

Você parece estar ansioso para pegar minhas declarações e colocá-las em um contexto de "o copo está meio vazio". Eu entendo, você está cético. Eu sugiro que nos poupemos de um monte de pressionamentos de tecla e discutamos propostas concretas de API, em vez de discuti-las em abstrato. Estou bastante convencido de que nosso plano fornecerá os pontos de extensão de que você precisa.

@terrajobst Não System.Text.JsonLab é o impl atual? isso significa que também oferecerá suporte para .NET Standard 2.0 e .NET v4.5?

Este pode ser um bom recurso para criadores de bibliotecas, mas você também deve considerar os desenvolvedores corporativos usando 50 bibliotecas com árvores de dependência e tentando encontrar compabilidades entre elas. Haverá configurações de mapeamento no estilo de redirecionamento de vinculação para tentar gerenciar as incompatibilidades?

Essa conversa parece nervosa, seja porque as pessoas foram ofendidas de alguma forma ou porque estão tentando se defender de uma ação que foi realizada ou não realizada. É difícil de ler. Desculpas por aí! Por favor, deixe o estado atual estar e siga em frente.

Parece que há duas razões para essa mudança. Em primeiro lugar, está o desejo de melhorar o desempenho utilizando novos tipos dentro do .Net Core.

Além disso, foi reconhecido que há algum tempo um erro arquitetônico foi cometido ao incluir referências rígidas a JSON.Net, uma biblioteca que reside externamente em .Net. Para corrigir isso, a introdução de uma nova implementação JSON embutida deve ser feita junto com interfaces que permitem que terceiros usem suas próprias implementações.

Isso vai quebrar as coisas? Sim! É por isso que o anúncio tem um rótulo de "alterações significativas" nele. (Talvez esse rótulo deva ser replicado aqui.) E como essa é uma mudança significativa, uma discussão foi iniciada para explorar o impacto. Além disso, para minimizar o impacto, será fornecida uma biblioteca adicional que permite que as pessoas continuem usando JSON.Net.

Como autor de uma biblioteca, estou muito interessado nisso e prefiro que a conversa continue.

@Tornhoof em resposta aos seus exemplos, se eu quiser continuar usando JSON.Net, também precisaria fazer referência à biblioteca de compatibilidade que mencionei anteriormente. Deve ser principalmente plug-and-play, mas pode haver mudanças. Eu definitivamente não quero que a estrutura (.Net Core) dite que o serializador que eu escolhi DEVE usar esses atributos para serialização, especialmente quando meu serializador usa um mecanismo diferente para conceitos semelhantes.

A solução fornecida pelo .Net deve ser mais genérica do que isso. O tratamento de serialização de modelo específico deve ser executado pela implementação JSON escolhida.

@mythz De tudo o que sei e vi das pessoas envolvidas na elaboração desta proposta, você terá uma longa chance de revisar e comentar a API proposta e a implementação antes de ser lançada como estável. Um dos propósitos de fazer esta postagem em um estágio tão inicial foi encontrar pessoas como você especificamente por esse motivo.

@gregsdennis
Não tenho certeza do que você quer dizer com mais genérico?
Supondo que seu serializador tenha o conceito de substituir nomes de propriedade json, alterando seu comportamento nulo e / ou implementações de fallback / pega-tudo e supondo que todos os três recursos fazem parte da especificação compartilhada para serializadores JSON para .net core 3.0, então o pacote de implementação mapeia esses atributos para seus detalhes de implementação internos.
Por exemplo, se sua biblioteca preferir que você use [DataMember] para especificar o nome das propriedades (como SpanJson faz), seu pacote de integração deve mapear facilmente.
Não estou dizendo que os atributos são a maneira certa, mas é uma parte visível do exemplo de código.

Obviamente, o mundo ideal seria que nenhuma biblioteca de estrutura do ASP.NET Core usasse quaisquer anotações específicas para controlar o comportamento de serialização, mas quanto ao recurso acima, isso é bastante complicado ou impossível, porque o RFC requer que certas regras de nomenclatura sejam seguidas .

De qualquer forma, acho que haverá muitas discussões sobre esses recursos compartilhados, como usá-los e descrevê-los no futuro.

Algum plano de usar instruções SIMD no novo analisador JSON, como no RapidJSON?

Referência: http://rapidjson.org/

A sugestão proposta parece boa, mas por favor, tente suavizar as " mudanças importantes ". Sou apenas um usuário comum de bibliotecas de terceiros e recentemente tive uma dessas experiências em que a reflexão foi repentinamente excluída do processo de construção de versão nativa UWP .net (compilador )

Portanto, nenhum dos meus aplicativos UWP pôde ser compilado no modo de lançamento por meses, pois tive que reescrever todo o código que usava reflexão em bibliotecas de terceiros. Eu sei que muitos autores de bibliotecas tiveram que dividir suas implementações novamente para excluir a reflexão nessas partes UWP. A maioria dos autores da biblioteca não compareceu à festa e fui forçado a abandonar o navio. Embora a MS tenha se destacado e se comprometido a implementar uma alternativa no padrão .net 2.1. sabemos que a realidade no terreno é .net padrão 2.1 levará meses para ser entregue desde a alteração inicial.

O ponto é simplesmente, este foi um processo extremamente perturbador para mim, que teve consequências enormes para os usuários finais e foi tudo menos "suave" e sem atrito.

Este é definitivamente o passo certo a fazer.
Estou me perguntando por um tempo vendo esta referência Json.Net.

@Tornhoof Acho que deve haver uma separação definida: as interfaces que cada provedor precisaria implementar para ser usado com .Net Core 3.0 e a implementação padrão que está embutida.

As interfaces devem ser de uso tão geral quanto possível. Talvez tão simplista quanto definir apenas os métodos Serialize() e Deserialize() .

Outros detalhes devem ser deixados para a implementação. Se a implementação padrão usou um atributo para definir um mecanismo de codificação de propriedade personalizada, estou bem com isso. Acho que é um detalhe específico da implementação que não deveria fazer parte da interface.

Dito isso, ter a capacidade de personalizar propriedades de chave pode ser um requisito, embora eu não tenha certeza de como isso poderia ser codificado.

@gregsdennis Sim, você está certo, eu estava olhando principalmente para o IInput / OutputFormatter, que já existe atualmente no ASP.NET Core e, especificamente, os problemas relacionados à sua substituição por versões não-JSON.NET.
De qualquer forma, como mostram seus comentários e @mythz , acho que a definição do escopo ficará interessante e provavelmente não tão simples (lembro-me dos problemas com as especificações da interface DI). Portanto, é melhor envolver muitos pontos de vista diferentes no início do processo.

@Tornhoof concordou. As interfaces do formatador atuais são distintamente baseadas em JSON.Net, mas não tanto no serializador em si, mas sim no objeto de opções. Parece que precisaríamos também de uma maneira genérica de comunicar opções (um objeto de opções comum).

Isso implica que o objeto de opções dita um conjunto mínimo de recursos para uma implementação? Eu acho que não. Recentemente, implementei um formatador para meu serializador que ignora completamente o objeto de opções, mas era para meu uso privado. Se eu quisesse fazer um para uso público, tentaria interpretar o máximo possível dessas opções para apoiá-las.

Não é assim que estamos fazendo as coisas. As opções são específicas do serializador e não há uma interface comum para elas. Os formatadores em MVC já estão devidamente fatorados e não acoplados a nada. JsonResult terá alterações significativas porque leva JsonSerializationOptions diretamente (o tipo JSON.NET).

Eu estava prestes a dizer a mesma coisa. Não planejamos construir uma abstração para um leitor / gravador / serializador JSON. Não é necessário; as estruturas lidam com primitivos de IO (como Stream , TextReader ) ou se conectam ao processamento de estrutura de nível superior (como os formatadores ASP.NET Core).

Falando de pontos problemáticos: Pessoalmente (e provavelmente sou uma minoria muito pequena), estou preocupado com a natureza frouxa de muitos analisadores JSON. Existe um padrão (tm), mas a maioria dos analisadores optou por ser tolerante e aceitar documentos não conformes. O que há de ruim nisso a longo prazo é que os desenvolvedores não implementam para um padrão que implementam para uma biblioteca. Se a biblioteca permitir documentos não conformes, os desenvolvedores ficarão satisfeitos, contanto que todos os bits usem a mesma biblioteca. A dor surge ao tentar se comunicar entre domínios que usam bibliotecas diferentes. De repente, há um problema porque diferentes bibliotecas suportam diferentes sabores de JSON.

Devemos remover os pontos problemáticos tornando a biblioteca JSON o mais tolerante possível (mas talvez acabe com complexidade e ambigüidade) ou atacando a causa raiz; bibliotecas JSON sem confirmação.

Como o MS influente, talvez haja muito o que pedir para que o MS defenda com sucesso os analisadores JSON em conformidade a fim de melhorar a interoperabilidade no longo prazo, mas gostaria que fosse diferente. Talvez seja leniente na leitura, mas rigoroso na escrita?

(Coisas que não estão no padrão; comentários, vírgulas finais, strings de aspas simples, sem strings de aspas e assim por diante)

IMHO, uma vez que JSON se origina do mundo do webbrowser, parece que, para interoperabilidade, devemos escolher double como a representação subjacente para números em JSON, embora o padrão JSON não diga nada sobre o representante.

Falando sobre a API, presumo implicitamente que a API mais comumente usada será uma API como o DOM, mas também acharia muito útil se houvesse uma API de nível inferior que me permitisse consumir o fluxo de token ou ser sinalizado em uma interface de visitante para aqueles grandes documentos dos quais desejo apenas extrair uma pequena parte dos dados.

@mrange - Por mais que eu goste de fazer as coisas o mais estritas possível ... fazer isso depende da capacidade de fazer alterações no código não conforme.

Se você estiver interagindo com um serviço legado sob o controle de alguma outra empresa, a capacidade de alterar o código ofensivo é quase zero. Mesmo estrito na gravação, embora mais factível, não está isento de problemas aqui: e se o código ofensivo espera receber um objeto não conforme enviado a ele?

@terrajobst obrigado! Func<Stream, CancellationToken, Task<T>> e Func<T, CancellationToken, Stream, Task> é tudo o que é necessário aqui. Com talvez algumas sobrecargas para TextReader / Writer, Span e string.

A desvantagem, entretanto, é quando você deseja serializar / desserializar o tipo de outra biblioteca, e esse tipo é decorado com atributos de um serializador json que você não está usando.

@thefringeninja se já estiver usando a biblioteca de terceiros para os objetos, então você já tem uma referência para o outro serializador. Nada mudou lá.

Não sou do tipo que defende o medo, mas acho que

@terrajobst Com relação ao ecossistema, embora seja impossível contabilizar todas as bibliotecas por aí, não acho que uma busca rápida por "json" no NuGet diria muito a alguém. Talvez o nome ServiceStack.Text não seja a maneira mais direta de dizer "Ei! Eu sou um pacote que pode (des) serializar JSON!", Mas houve benchmarks ao longo dos anos comparando-o. Talvez seja um caso de dogfooding os padrões do MS e não saber a amplitude e popularidade das alternativas ou usá-las internamente com frequência suficiente para estar familiarizado com elas.

Concordo que deve haver algum padrão para fornecer uma experiência que _ simplesmente funcione_ fora da caixa. Se outros autores de bibliotecas no ecossistema publicarem um pacote de integração, seria ótimo se eles pudessem obter um plug-in nos documentos, notas de lançamento, etc. para enfatizar que existem alternativas além dos padrões. Tornar difícil a descoberta seria problemático para o ecossistema.

Minha esperança é que, se o objetivo de remover a dependência for sincero, as APIs representem melhor as necessidades da comunidade e não sejam modeladas diretamente após Json.NET. O resultado final é que vai exigir o trabalho de todos os autores da biblioteca, não apenas do ServiceStack, mas as APIs não devem se parecer diretamente com a API do Json.NET, caso contrário, você está de volta ao que parece ser uma dependência, mas sem a dll.

as APIs não devem se parecer diretamente com a API do Json.NET

... ou a implementação de qualquer outro provedor específico.

Parte da discussão que ocorreu antes do anúncio incluiu a ideia de que a equipe do .Net se basearia em várias bibliotecas para ter uma ideia de como vários problemas foram resolvidos e, em seguida, usar o que considerou ser o melhor ajuste deles ideias combinadas com as suas. Em muitos aspectos, não é diferente de como qualquer outra nova biblioteca JSON seria desenvolvida; acontece que este será incluído no framework.

Estamos empenhados em ter uma biblioteca JSON de alto desempenho que não precisamos construir nós mesmos. :)

Antes de discutir qualquer coisa, considere aproveitar os resultados da pesquisa da Microsoft nessa área (mais especificamente, a não ramificação, não a análise FSM) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -análise de dados/

Estamos indo nessa direção para análise JSON de alto desempenho --- além de Span<T> claro ---
cc @terrajobst @karelz

:( toda essa discussão sobre JSON me faz sentir que minha pergunta sobre os modelos não está correta.

Eu gostaria de ter mais tempo para esta discussão porque tem sido um inferno, mas vejo por que se tornou o que é. 4.6.1 tem que ser consistente com upgrades e upgrades e as alterações de interrupção serão para o resto.

Eu vi muitos pacotes recuperados para core e 461 e espero que este tipo ou mudança conserte isso.

Estou preocupado que o problema em cascata nos assombre, por favor, prove que estamos errados.

// dot net devs em todos os lugares

@ c0shea

[...] seria ótimo se eles pudessem obter um plug-in nos documentos, notas de lançamento, etc. para enfatizar que existem alternativas além dos padrões.

Tenho certeza de que será o caso. Os documentos já listam implementações alternativas para vários tópicos, como contêineres DI , provedores de registro , integração Swagger ou provedores de banco de dados EF Core .

@ phillip-haydon
O sistema de modelos já oferece suporte a modelos personalizáveis ​​e, na verdade, os modelos existentes já têm várias opções. Basta verificar, por exemplo, dotnet new mvc --help para saber o que é possível no momento. Tenho certeza de que você poderia facilmente estender isso com, por exemplo, integrações alternativas de serializador JSON e solicitações de recursos ou pull para que provavelmente serão aceitas em aspnet / Templates .

@mrange - Por mais que eu goste de fazer as coisas o mais estritas possível ... fazer isso depende da capacidade de fazer alterações no código não conforme.

Se você estiver interagindo com um serviço legado sob o controle de alguma outra empresa, a capacidade de alterar o código ofensivo é quase zero. Mesmo estrito na gravação, embora mais factível, não está isento de problemas aqui: e se o código ofensivo espera receber um objeto não conforme enviado a ele?

Talvez tenha um modo estrito por padrão e seja capaz de alterná-lo explicitamente para um modo mais tolerante

@poke Eu acho que você realmente precisa experimentar o vue cli e, em seguida, tentar novamente em novo novo. O novo dotnet atual ... é ... é ...

Posso solicitar que você se lembre de que a análise de JSON dos vários navegadores não oferece suporte a valores int64 corretamente e nos dá a capacidade de serializar / desserializar longs como strings? É uma daquelas coisas que você não percebe até que o morda com força. Uma variação disso é ser capaz de decidir se os números são desserializados em ints ou longos por padrão.

Posso solicitar que você se lembre de que a análise de JSON dos vários navegadores não oferece suporte a valores int64 corretamente e nos dá a capacidade de serializar / desserializar longs como strings? É uma daquelas coisas que você não percebe até que o morda com força. Uma variação disso é ser capaz de decidir se os números são desserializados em ints ou longos por padrão.

.... Ah, EcmaScript, obrigado por fazer tudo duplo. Tenho certeza de que não causou problemas em alguma outra parte do código ...

Como purista, não gosto de coisas assim.
Como realista, acho que terei de concordar com isso.

Alguma parte da nova implementação JSON estará em .Net Standard 2.1 ?

Tenho acompanhado isso um pouco e não tenho certeza se perdi. Existe uma superfície ou interface de API proposta que eu possa revisar? Estou interessado em ver a área de superfície da API para esta proposta.

Existe uma superfície ou interface de API proposta que eu possa revisar?

Ainda há muito a fazer, mas https://github.com/dotnet/corefx/pull/33216 é um começo. Aqui estão as notas de revisão da API .

ATUALIZAÇÃO: Roteiro também disponível aqui .

então, como o recurso completo será o api do aspnet 3.0 comparado ao api json.net? Além disso, json.net para todos os efeitos e propósitos será eliminado pelo desenvolvimento de novos aplicativos com APIs nativas?

apenas melhorar o desempenho ou significa substituir todas as funções do json.net?

Esta é uma notícia incrível.

Eu recomendo fortemente tentar colaborar com @neuecc, seu trabalho com MessagePack , Utf8Json , ZeroFormatter etc tem sido fenomenal.

@linkanyway, o resultado seria substituir um subconjunto de json.net, fornecendo novas apis sem alocação.

Eu suspeito que a maioria dos usuários do aspnet não teria uma forte dependência da implementação do json.net e seria capaz de migrar quase perfeitamente.

Existe uma superfície ou interface de API proposta que eu possa revisar?

Ainda há muito a fazer, mas dotnet / corefx # 33216 é um começo. Aqui estão as notas de revisão da API .

ATUALIZAÇÃO: Roteiro também disponível aqui .

@khellang Vamos conseguir alguma ajuda lang para que possamos escrever json em c # de verdade?

Mais um bom movimento na direção do OSS. Vai motivar os desenvolvedores de outras plataformas comerciais a desenvolver algo melhor do que a MS já faz de graça, ou tornar-se totalmente OSS se realmente se preocuparem com a comunidade.

Vamos conseguir alguma ajuda lang para que possamos escrever json em c # de verdade?

@dotnetchris Não tenho certeza do que você quer dizer com "lang help". Literais JSON? Duvido que isso aconteça. Você já olhou para o próximo recurso de "linguagem incorporada"? Especificamente para JSON ?

@khellang isso é certamente um passo na direção certa, mas quero dizer apoio total. Usando os mesmos objetos de amostra do seu link, mais parecido com:

json v1 = { 
                    first: 0, 
                    second: ["s1", "s2" ] 
                }

var andCsharp = v1.second.Where(item => item.EndsWith("1"));

Com vodu suficiente, como a geração implícita de tupla / conjunto de valores / objeto de registro para fazer com que tudo funcione no nível de idioma nos bastidores.

Por outro lado, o compilador pode invocar os serviços json, criar uma classe e, em seguida, trabalhar com uma instância da classe como se você escrevesse:

var v1 = "{ first: 0, second: ['s1', 's2' ] }".Deserialize<MyV1>();

Editar: LOL @ downvoters.

@dotnetchris https://github.com/dotnet/csharplang/issues/1238

@dotnetchris Se você estiver interessado, vote em https://github.com/dotnet/roslyn/pull/24110. Ele foi fechado pela equipe do IDE por falta de interesse. Mas se houver votos suficientes, talvez isso possa mudar.

As APIs JSON “integradas” e “fornecidas pela plataforma” significam que não será um pacote nuget separado (netstandard)? Se não, por que não?

Suponho que a nova estrutura compartilhada ASP.NET Core não pode depender de pacotes de nuget, ou pode?

Já não existe um namespace System.Json ? É este o namespace que será usado / expandido para .NET Core 3.0 e, finalmente, .NET Standard. Esse namespace já é usado (pode não ser muito usado, mas está disponível 😅) no Xamarin.Android 7.1+, Xamarin.iOS 10.8+ e Xamarin.Mac 3.0+.

Removê-lo quebraria a compatibilidade com versões anteriores. Saí-lo e iniciar uma nova API pode causar alguma confusão. Expandir / aprimorá-lo sem remover quaisquer APIs pode ser um pouco restritivo ao adicionar novas APIs.

Seria ótimo ter interfaces para JsonReader / JsonWriter, porque existem outras origens e destinos além de apenas fluxos. Por exemplo, também uso JSON.NET para MongoDB. É mais rápido e não preciso manter vários serializadores em meus aplicativos.

Sei que pode prejudicar um pouco o desempenho, mas é muito útil.

@SebastianStehle : JsonReader / JsonWriter são abstrações de alto nível, consulte o comentário do terrajobst

O plano para 3.0 é o seguinte:

1. APIs JSON de alto desempenho integradas. Leitor / gravador de baixo nível, um leitor / gravador baseado em Stream e um> serializador.
2. O ASP.NET Core pode ser conectado ao componente JSON.

Há uma questão em aberto sobre o que os modelos para ASP.NET 3.0 usarão. Dependendo da fidelidade que podemos fornecer pelo 3.0, podemos fazer com que eles incluam o pacote de integração Json.NET. No entanto, o objetivo é fornecer fidelidade e paridade suficientes para depender apenas dos integrados por padrão.

A API de alto nível e fácil de usar seria envolvida em streams para desserializar facilmente de e para streams (isso geralmente é mais comum, ao serializar. Se você deseja melhor desempenho em cenários onde não pode usar streams, deve usar o APIs de nível que operam em Span<T> ou Memory<T> , especialmente quando você tem os dados já disponíveis / na memória que deseja usar e não tem a sobrecarga de assíncrono.

@TsengSR

https://github.com/neuecc/Utf8Json não fornece a funcionalidade para escrever leitores / gravadores personalizados por motivos de desempenho (chamadas virtuais e alocações, eu acho) e pensei que eles gostariam de seguir o mesmo caminho. Mas até agora não vi nenhum código de serialização ainda.

Eu concordo com @ JonasZ95 e @gregsdennis , espero que a implementação não seja uma simples abstração dos mesmos detalhes de implementação JSON.Net, mas sim enfoque em sua aparência _deve_.

Eu também acho que deve ser abordado como 2 funções distintas ...

1. serialização / desserialização
2. versão json da referida serialização e desserialização.

Esperançosamente, a estrutura do ASP.NET Core usará uma abstração de serialização genérica em vez de uma abstração específica de JSON.

No que diz respeito à extensibilidade, espero que o framework use a técnica DI de codificação para abstrações (interfaces, não classes abstratas) e simplesmente forneça um padrão local. Da perspectiva dos autores da biblioteca JSON, isso forneceria a maior extensibilidade, porque tudo o que você teria a fazer é fornecer uma classe de adaptador ASP.NET Core que usa a implementação de biblioteca das interfaces e, em seguida, configurar o ASP.NET Core para usar o adaptador de biblioteca.

A implementação de uma biblioteca de terceiros pode ser semelhante a esta:
`` `C #
// referenciar bibliotecas de terceiros
using Newtonsoft.Json;

// exemplo muito ingênuo para brevidade apenas para
// Faça o ponto
public class NewtonsoftAdapter: ISerializer
{
private JsonSerializerSettings _settings;
formatação privada _format;

public NewtonsoftAdapter(JsonSerializerSettings Configuration, Formatting FormatOption)
{
    _settings = Configuration;
    _format = FormatOption;
}

    // interface method
public string Serialize<T>(T Subject)
{
    return JsonConvert.SerializeObject(Subject, _format, _settings);
}

    // interface method
public T Deserialize<T>(string SerializedContent)
{
    return JsonConvert.DeserializeObject<T>(SerializedContent, _settings);
}

}

...

// configuração do adaptador com opções de personalização de terceiros
var settings = new JsonSerializerSettings
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = new NewtonsoftAdapter (configurações, Formatting.Indented);

// configurar núcleo asp.net
// onde o adaptador implementa ISerializer (ou qualquer nome que você inventar)
// os autores da biblioteca podem até fornecer seu próprio método de extensão UseXYZ ().
app.UseSerializer (adaptador);
`` `

Houve muitos avanços na análise de texto baseada em SIMD, inclusive para texto estruturado, como JSON . Há alguma chance de que o trabalho no .NET Core se aproxime desse nível de desempenho? Existe alguma maneira de usar essas técnicas?

Ei, até a Microsoft Research tem algumas novas soluções de alto desempenho!

@AnthonyMastrean Obrigado por trazer isso à tona. Também estou interessado em quaisquer benchmarks para ter uma ideia de como este impl Json atual se compara ao simdjson.

A propósito, os autores de simdjson disseram que ainda estão trabalhando na publicação completa deste projeto (acho, mais doc). Por enquanto, você pode ler algumas discussões interessantes sobre este projeto na HN .

Existe alguma maneira de usar essas técnicas?

O .NET Core 3.0 acaba de entregar um monte de intrínsecos dependentes da

Pelo que vale a pena, acho que no escopo da web, a rede é um gargalo primário e, embora seja legal que você possa analisar gigabytes em segundos, não acho que seja muito útil para um projeto da web.

Não me interpretem mal, otimizações de desempenho como essas são muito legais e provavelmente beneficiariam até mesmo documentos JSON muito pequenos. Mas, por enquanto, acho que o foco com a nova biblioteca é evitar a alocação de memória e mover tudo muito próximo à camada de rede. Só isso já deve melhorar muito o desempenho em relação ao JSON.NET. Mas quando o trabalho inicial estiver concluído, olhar para otimizações adicionais pode ser outra história.

Onde eu trabalho, analisamos tera bytes de JSON todos os dias. Também conheço outros que usam .NET e F # para processar muitos documentos JSON. JSON se tornou mais do que servidor => mecanismo de transporte do navegador. É muito usado em cenários de back-end puros.

CLARO; seria melhor para o back-end mudar para um formato binário como AVRO / Protobuf, mas geralmente isso é difícil e JSON tem alguns benefícios (eu admito a contragosto). Ter um analisador JSON muito rápido poderia literalmente economizar US $ 10.000 dólares por mês para empresas semelhantes a nós.

@poke Este projeto se enquadra no .NET Core (não ASP.NET ...), portanto, é relevante para todas as cargas de trabalho, não apenas para a web.

Posso concordar com a ideia de que é tarde demais para trabalhar nesta técnica de otimização específica para .NET Core 3.0, mas espero que alguma investigação seja feita agora para garantir que a otimização será possível no futuro (ou seja, sem interromper as alterações )

Pode ser melhor fazer algo como um conjunto de mapeamento unificado ('System.Text.Json.Mapping'), onde definir atributos e outras coisas para mapear JSON para classes C #? Depois de implementar isso, todos os analisadores / gravadores JSON existentes podem ser adotados para usar o mapeamento unificado. Ele permitirá que todos os aplicativos .NET Standard migrem entre diferentes bibliotecas JSON sem qualquer problema

@AlexeiScherbakov Novas abstrações não ajudam muito. Você apenas se limitará novamente ao escolher uma abstração comum e sempre haverá novas bibliotecas que não podem usar a abstração e exigem mais. Sempre foi assim, por exemplo, com o registro .

Não acho que criar uma nova abstração com base nessa nova implementação nos trará qualquer benefício, especialmente quando a biblioteca foi projetada para ser muito menos rica em recursos de qualquer maneira.

E na verdade já existe uma abstração padrão de rede existente na forma de DataContract / DataMember que espero que esta biblioteca acabe respeitando (mesmo que essa abstração seja um pouco limitada).

Além de um atributo de ignorar, não podemos ter um bilhão de novos atributos e cenários para atender. Prefere mapeamento 1: 1 de JSON para classes, se você quiser fazer algo fora da norma ou oferecer suporte ao legado, use json.net.

Pessoalmente, não me importo muito com as classes JSON <=> C #. Eu acho que é importante ter o conceito de análise / gravação de JSON separado do modelo de objeto C # criado do modelo JSON.
Dessa forma, eu (que não me importo muito com as classes JSON <=> C #) posso ter um analisador realmente eficiente sem dar voltas em algum tipo de modelo de objeto.

@mrange é para isso que o leitor e o escritor existem

Isso significa que posso esperar uma API de leitor / gravador na API JSON fornecida pela plataforma? O padrão Reader / Writer é o mais eficiente?

Existem 3 tipos em System.Text.Json partir de agora :

• Utf8JsonReader - uma maneira rápida, sem cache e somente de encaminhamento para ler texto JSON codificado em UTF-8.
• Utf8JsonWriter - ^ igual a Utf8JsonReader , mas para escrita.
• JsonDocument - um modelo de documento de acesso aleatório somente leitura para cargas JSON.

Todos os tipos acima devem ser (mais ou menos) livres de alocação 👍

Postamos o artigo simdjson: https://arxiv.org/abs/1902.08318

Também há trabalho em andamento em uma porta C # de simdjson: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

Pode ser melhor fazer algo como um conjunto de mapeamento unificado ('System.Text.Json.Mapping'), onde definir atributos e outras coisas para mapear JSON para classes C #? Depois de implementar isso, todos os analisadores / gravadores JSON existentes podem ser adotados para usar o mapeamento unificado. Ele permitirá que todos os aplicativos .NET Standard migrem entre diferentes bibliotecas JSON sem qualquer problema

Eu realmente espero que a nova abstração não dependa de atributos. Tento usar objetos POCO limpos nas bibliotecas subjacentes e uso DI para evitar que eles tenham que saber sobre a implementação. Definitivamente, não quero decorar minhas classes subjacentes com atributos necessários para a implementação. Isso pode acabar fazendo com que classes extras sejam criadas nas camadas da interface do usuário, que essencialmente apenas mapeiam um objeto de domínio existente para json.

Provavelmente, o mapeamento 1-1 de classes json para c # seria uma abordagem melhor, pelo menos em alguns casos você poderia evitar a criação de novas classes, mesmo se as classes do tipo viewmodel ainda fossem necessárias em outros casos.

No entanto, seria bom se houvesse alguma forma de ignorar propriedades que não são necessárias e, pelo menos, controlar alguns dos aspectos de serialização (como camelo vs casing pascal).

@mrange é para isso que o leitor e o escritor existem

@davidfowl Isso significa que as novas APIs estão seguindo esse caminho? O design foi finalizado?

O suporte de serialização está chegando enquanto falamos . O problema relacionado diz:

• Devido às limitações de tempo e para obter feedback, o conjunto de recursos destina-se a um produto mínimo viável para 3.0.
• Os cenários de objeto POCO simples são direcionados. Normalmente são usados ​​para cenários de DTO.
• A API projetada para ser extensível para novos recursos em versões subsequentes e pela comunidade.
• Atributos de tempo de design para definir as várias opções, mas ainda oferecem suporte a modificações em tempo de execução.
• Alto desempenho usando IL Emit com fallback para reflexão padrão para compatibilidade.

Ele também detalha como eles estão planejando oferecer suporte à conversão de enum, manipulação de nulos, camel- vs PascalCasing etc.

Se você tiver algum feedback sobre isso, deve deixar seus comentários nessa edição ou na solicitação de pull.

@lemire Uau, isso é muito legal. simdjson é realmente super rápido.

Alguma chance de você implementar o benchmark de serialização JSON do TechEmpower ? (Eu sei que vai dar muito mais trabalho)

Encontrei estas implementações: No repositório TechEmpower e no repositório ASP.NET .

@KPixel Isso é serialização, certo? Enquanto isso, simdjson é um parser ... A menos que eu esteja confuso sobre os termos, essas coisas vão em direções opostas?

Foi mal. Presumi que havia uma parte de desserialização (que usaria o analisador).

O System.Text.Json será um pacote nuget padrão .net? ou é algo que só está disponível para .net core 3.0?

@ John0King dê uma olhada aqui: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Acho que a usabilidade também deve ser o foco do novo pacote JSON. Um recurso que acho que deveria ter é o suporte à validação de esquema JSON. A Newtonsoft cobra por isso. Isso é algo fundamental o suficiente para ser disponibilizado gratuitamente na plataforma, como era o caso da validação do esquema XML.

@ jemiller0 Minha impressão é que a validação XML tem sido um tanto confusa e o esquema JSON teve uma adoção moderada na palavra real. Você sempre pode ter uma verificação de esquema por meio de uma biblioteca como uma etapa extra ... Claro, isso pode envolver a aquisição de uma licença de software, mas é um grande negócio?

@lemire Sim, é grande coisa, se você está desenvolvendo software de código aberto e deseja disponibilizá-lo para todos. A análise de XML não é uma mistura de misturas. Funciona. A mesma coisa com a validação do esquema JSON. Não ter uma maneira gratuita integrada de fazer isso torna a plataforma .NET não competitiva.

Nunca vi esquema json usado no mundo real. Mesmo assim, não deve fazer parte da implementação discutida aqui. E nenhum dos bilhões de outros recursos e peculiaridades do json.net também devem ser implementados aqui. Isso não deve ser nada mais do que uma implementação rápida superleve. Se você não estiver satisfeito por precisar de uma licença para json.net para suportar a validação json. Crie sua própria implementação de código aberto e torne-a disponível gratuitamente.

@ jemiller0

Estou genuinamente curioso: outras linguagens de programação oferecem suporte ao esquema JSON em sua biblioteca padrão?

O objetivo desta biblioteca é ser uma biblioteca de baixo nível e alto desempenho para trabalhar com JSON. Qualquer coisa que não seja isso, que inclui a maioria dos recursos mais avançados do JSON.NET e também os esquemas JSON, não fará parte disso.

Se quiser a validação do esquema JSON, você está livre para implementar um validador no topo desta biblioteca, que deve ser de nível baixo o suficiente para permitir que você faça isso.

Não acredito que ter a validação do esquema JSON em uma biblioteca padrão tenha algo a ver com uma plataforma ser competitiva ou não.

O objetivo desta biblioteca é ser uma biblioteca de baixo nível e alto desempenho para trabalhar com JSON. Qualquer coisa que não seja isso, que inclua a maioria dos recursos mais avançados do JSON.NET, não fará parte disso.

Exceto que também incluirá recursos de nível superior, projetados para substituir o Newtonsoft.Json 😊

@poke Você tem o direito de ter qualquer opinião que queira, assim como eu. XML é usado em todo lugar. Portanto, com razão, a Microsoft incluiu suporte de validação com o .NET Framework. Agora, JSON está na moda e é usado EM TODOS OS LUGARES, em arquivos de configuração, APIs da web, etc. etc. Faz sentido ter o mesmo nível de suporte para JSON que era historicamente suportado para XML. Pessoalmente, acho um pouco ridículo que a Microsoft esteja usando software de terceiros para começar. Esse deve ser um recurso central da plataforma.

@lemire Em breve estarei verificando o Python. Nesse ponto, descobrirei que ele está integrado ou incluído como um pacote de fácil instalação. Eu ficaria muito surpreso se não fosse. Estou pensando em usar o NJsonSchema para o que preciso agora. Logo de cara, você pode ver que a documentação é uma merda. Sim, confiar em bibliotecas de terceiros que podem ou não ser de qualidade é uma ótima ideia para coisas como trabalhar com JSON, que é totalmente onipresente e usado em todos os lugares. Vamos todos confiar no software comercial ou em pacotes de terceiros sem documentação. .NET não deve apenas corresponder a outras plataformas como Python. Eles devem vencê-los, fornecendo software de qualidade com documentação apropriada pronta para uso. É assim que tem funcionado historicamente. Onde eu trabalho, todo mundo odeia .NET e quer me forçar a usar Python. Não sei se você percebeu, mas, mais e mais pessoas estão abandonando o navio e mudando para Python. Dizer ao meu chefe que preciso comprar uma licença para fazer algo simples como validar JSON não funcionará. O que vou receber em troca é questionar por que eu gostaria de usar o .NET em primeiro lugar. Não importa o fato, que se trata de um projeto de código aberto onde você não pode obter uma licença de qualquer maneira. Com sorte, descobrirei que o NJsonSchema simplesmente funciona. Estou apenas apontando uma omissão gritante na estrutura que deve ser óbvia para qualquer pessoa que trabalhe com JSON.

Eu uso esquemas JSON no trabalho e prefiro ter um analisador JSON muito bom do que meio analisador JSON bom + validador de esquema JSON. Além disso, o esquema AFAIK JSON é um _draft_ 7 agora. Portanto, ter o esquema JSON como uma biblioteca externa que pode evoluir rapidamente junto com o esquema faz sentido para mim. Ter o esquema JSON no roteiro seria bom, entretanto.

@ jemiller0

Faz sentido ter o mesmo nível de suporte para JSON que era historicamente suportado para XML.

.Net também inclui suporte para XSLT e XPath. Se você deseja "mesmo nível de suporte", isso não significa que também precisaria de alguma versão daqueles para JSON?

O que estou tentando dizer é: o ecossistema JSON é diferente do ecossistema XML. Ambos têm padrões de uso diferentes e as tecnologias relacionadas têm números de uso e níveis de padronização diferentes. Além disso, o XML foi adicionado ao .Net antes de NuGet, git ou GitHub existirem. Hoje em dia, é muito mais fácil e mais aceitável contar com uma biblioteca de terceiros.

Portanto, não, não acho que faça sentido dizer cegamente "XML tinha isso, então JSON tem que ter também".

Além disso, a validação é simplesmente ortogonal à análise. Eu ficaria absolutamente bem com a adição de suporte de validação em algum ponto (possivelmente em outro pacote). Mas não é necessário para o suporte de análise adequado.

Precisamos de uma forma de validação estrita de dados em solicitações REST da API.
Porque salvamos o json que vem por meio da API sem erros e, posteriormente, não podemos analisá-lo em JS por causa de vírgulas à direita e assim por diante.

E por que você não pode validar esse pedido agora?

@ phillip-haydon @ freerider7777 Acho que qualquer analisador JSON decente deve obedecer à especificação JSON e lançar erros (e / ou avisos) quando o documento não estiver bem formado (por exemplo, quando tiver vírgulas à direita). Isso é muito básico, mas também diferente da validação, que é a comparação dos dados JSON com um esquema (pelo menos, é assim que uso os termos).

https://tools.ietf.org/html/rfc7159

A Microsoft, uma das maiores empresas de desenvolvimento de software que existe, não tem ninguém para trabalhar na validação. Um analisador rápido é mais importante. Isso permitirá que você analise o JSON inválido na velocidade da luz. :-) Não ocorreu a ninguém que a validação rápida poderia ser útil. Assim como o ASP.NET Core, uma atualização rápida e simplificada para Web Forms.

E por que você não pode validar esse pedido agora?
@ phillip-haydon No código do controlador com tal json:
ModelState.IsValid == true

🤦‍♂️

Você pode fazer a validação com base em seu esquema json já com NSwag + System.ComponentModel.DataAnnotations :

<Project Sdk="Microsoft.NET.Sdk" >
  <ItemGroup>
    <PackageReference Include="NSwag.MsBuild" Version="12.0.10" />
  </ItemGroup>
  <ItemGroup>
    <Compile Remove="**\*.g.cs" />
  </ItemGroup>
  <ItemGroup>
    <SchemaFiles Include="$(MSBuildProjectDirectory)\..\schema\*.json" InProject="false" />
    <EmbeddedResource Include="$(MSBuildProjectDirectory)\..\schema\*.json" LinkBase="Messages\Schema" />
  </ItemGroup>
  <Target Name="GenerateMessageContracts" BeforeTargets="GenerateAssemblyInfo">
    <Exec Command="$(NSwagExe_Core21) jsonschema2csclient /name:%(SchemaFiles.Filename) /namespace:MyNamespace.Messages /input:%(SchemaFiles.FullPath) /output:$(MSBuildProjectDirectory)/Messages/%(SchemaFiles.Filename).g.cs" />
    <ItemGroup>
      <Compile Include="**\*.g.cs" />
    </ItemGroup>
  </Target>
</Project>

Eu concordo com @lemire , há uma diferença em validar a estrutura do JSON e validar o JSON em relação a um esquema. Não tenho dúvidas de que a Microsoft gastou tempo e esforço para implementar corretamente o primeiro ... o último é um caso esquivo e não acho que se encaixa no design geral desta biblioteca JSON. Tenho certeza de que eles deixaram claro que esta biblioteca JSON foi projetada SOMENTE para fornecer análise rápida e eficiente conforme necessário para que o núcleo do asp.net opere. Não foi projetado para incluir os _extras_ fornecidos com o analisador da newtonsoft. (consulte o comentário de @poke anteriormente no tópico).

Não acho que o fato de eles não terem projetado isso intencionalmente para vir com todos os sinos e apitos o torne um produto inferior.

Isso aconteceu com o preview 4?

Existem planos para tornar o System.Text.Json.Serialization.Policies.JsonValueConverterclasse pública para permitir a substituição de classes de conversor de Json.net?

System.Text.Json enviado com suporte completo .Net via nuget? Seria bom garantir a interoperabilidade total, bem como aproveitar os benefícios de toda a estrutura.

System.Text.Json foi recentemente alterado para produzir netstandard2.0 binários para envio OOB; https://github.com/dotnet/corefx/pull/37129 :

Se possível, você deve direcionar o .NET Core 3.0 e obter as APIs System.Text.Json embutidas. No entanto, se você precisar suportar netstandard2.0 (por exemplo, se você for um desenvolvedor de biblioteca), você pode usar nosso pacote NuGet que é compatível com netstandard2.0.

benefícios da estrutura completa

O que são isso de novo? 🤔

@khellang

Minha preferência seria um nuget com vários sabores, incluindo framework completo (4.5 ou o mínimo aceitável), padrão e núcleo. Usar montagens em caixa é preferível.

O problema vinculado acima se refere a este pacote, mas não é compatível:

https://www.nuget.org/packages/System.Text.Json

Existe um pacote com suporte atual?

Minha preferência seria um nuget com vários sabores, incluindo framework completo (4.5 ou o mínimo aceitável), padrão e núcleo.

Por que você prefere isso? Se não houver necessidade de múltiplos destinos, ou seja, todas as APIs usadas fazem parte do padrão, é muito melhor ter apenas um único destino 😊

Existe um pacote com suporte atual?

Acho que ainda não foi enviado. O PR foi fundido dias atrás. Esse pacote costumava ser um projeto comunitário que agora foi transferido para o MS.

@khellang , depende dos detalhes - eu estava fazendo uma declaração geral.

Se a versão padrão da rede tivesse que omitir algo da versão do núcleo da rede que seria possível com a versão completa da rede, eu preferiria que todos os três sabores estivessem disponíveis. Mesmo raciocínio geral, eu suspeito, que a declaração original do problema vinculado acima sobre preferir que os usuários direcionem a versão na caixa.

Ao adicionar uma referência ao pacote nuget, o tipo mais compatível apropriado seria selecionado automaticamente. Portanto, não é grande coisa. Se a biblioteca de consumo for padrão da rede, o tipo padrão da rede será selecionado.

Minha preferência geral por versões em caixa é que quando eu goto definition , obtenho fontes descompiladas. Se eu goto definition em bibliotecas padrão da rede, normalmente vejo apenas fontes de stub que lançam NotImplemented exceções.

benefícios da estrutura completa

O que são isso de novo? 🤔

Muitos aplicativos usam o .NET Framework não porque querem absolutamente ficar fora do .NET Core, mas porque o .NET Core não é uma opção. Eu uso o .NET Core quando é uma opção; quando preciso direcionar versões do Windows anteriores ao Windows Server 2012 (a versão mínima do .NET Core 3.0), preciso usar o .NET Framework. Por mais que eu tenha certeza de que foi uma decisão muito dolorosa interromper o suporte para Windows Server 2008 R2 e versões anteriores, é uma decisão muito dolorosa para todas as empresas com clientes pagantes com servidores que eles não querem atualizar / muitas vezes basicamente recriar do zero apenas para que possamos usar uma ferramenta um pouco mais recente.

Ninguém ficaria mais feliz do que eu se eu pudesse parar de usar o .NET Framework amanhã, mas mesmo com todas as oportunidades de WPF e Windows Forms no .NET Core 3.0 e além, a Microsoft está tornando isso uma impossibilidade prática com suas políticas de suporte. Tentei discutir isso com qualquer pessoa que quisesse ouvir na Microsoft, mas, infelizmente, ainda não recebi um e-mail confirmando que a mensagem foi entregue.

@JesperTreetop para não mencionar a falta de suporte LTS para as versões do .NET Core que valem a pena usar para uma empresa;) Espero obter suporte LTS no 3.x - como arquiteto .NET da minha organização, estarei buscando Adoção do .NET Core se conseguirmos uma versão 3.x com suporte LTS.

@marksmeltzer A postagem do blog Introduzindo o .NET 5 de ontem mostra que o .Net Core 3.1 será LTS e está planejado para ser lançado em novembro de 2019.

Este novo serializador JSON suportará tipos F #?

@rliman bem, atualmente ele não suporta Guid ou Enum, então tem um longo caminho a percorrer. Eu concordo que o suporte total para tipos de opção F # sendo semelhantes a C # anulável deve ser necessário IMHO

Pessoalmente, acho que essa é uma solução apressada para uma má decisão de projeto arquitetônico. Isso deveria ter sido feito há muito tempo ... Agora vai causar muita dor em todos os lugares ... De desenvolvedores de bibliotecas a desenvolvedores corporativos.

Não existe uma maneira fácil de "suavizar" esse novo "recurso".

Este é o MS tentando resolver um problema que eles causaram em primeiro lugar. E agora todos têm que pagar o preço.

Com o NET Core parece desde o início que o vagão é um pouco "veloz" ... Essa abordagem "ágil" pura pode precisar diminuir um pouco a velocidade e permitir que todos recuperem o fôlego.

Parece que com o ASP.NET Core esses "recursos" (alterações importantes) tornaram-se o novo normal.

Em minha opinião, o ASP.NET Core precisa desesperadamente de um retrabalho em seu processo de design de arquitetura. Porque sempre faço esses recursos de "consertaremos mais tarde".

Tenho desenvolvido com ASP.NET Core desde os primeiros betas ... E é uma grande melhoria no .NET.

Mas a equipe de MS deve parar por um momento e pensar como eles podem resolver o problema real aqui: decisões de projeto arquitetônico apressadas e inconsistentes.

Basta voltar e ler outros tópicos ... Parece que é um tema recorrente.

Então, pode ser que seja hora de sentar e repensar qual é a melhor abordagem para fazer um produto mais estável.

O .NET clássico pode não ser tão poderoso quanto o Core ... Mas é muito estável e consistente desde o 2.0.

Apenas minha opinião.

Olá @suncodefactory ,
Lembro-me de algum tempo atrás, quando ppl gritou com ms por não usar bibliotecas de código aberto, agora eles são culpados por fazer isso: D
Do meu ponto de vista Aspnet / core MVC api têm sido muito estáveis ​​desde mvc1 / 2! A razão pela qual o aspnet era estável desde 2.0 é que ele nunca mudou / melhorou de forma alguma 😄.
Para ser honesto, se você estiver usando um recurso avançado de uma biblioteca de serialização, você terá a chance de repensar sobre isso e talvez abordar o problema com uma estrutura de dados adequada para a tarefa, em vez de fingir que todos os serializadores suportam todos os recursos de linguagem, imo é o problema errado para resolver e a maneira errada de usar a serialização.
Clareza, compatibilidade com versões anteriores e extensões futuras são o que impulsiona meus dtos serializáveis, trocas muito diferentes usadas em objetos de lógica de negócios comuns (aqueles são privados, têm muitas funções, etc.)

Conseguimos mover microsserviços do net framework para o Linux (net core) sem quase nenhum esforço das equipes prudentes. Não sei do que vocês estão falando. A Microsoft está fazendo um ótimo trabalho ao espalhar a implementação de mudanças como essa, que eram esperadas há muito tempo.

Olá @suncodefactory ,
Lembro-me de algum tempo atrás, quando ppl gritou com ms por não usar bibliotecas de código aberto, agora eles são culpados por fazer isso: D

Para mim, a questão não é sobre bibliotecas de terceiros ... É sobre projeto arquitetônico que, neste caso específico, está faltando ou simplesmente está errado.

Também nunca falei sobre o asp.net clássico ... estava falando sobre o .NET Framework 2.0. E a razão de ele estar estável não foi porque não houve melhorias, como você afirma falsamente (uma vez que .net core é baseado em .NET 4.6.1). O motivo foi porque foi bem planejado e arquitetado.

Quanto ao quão bom é o aspnet core em comparação com o asp.net mvc clássico, que não tem nada a ver com este tópico específico.

Este tópico é sobre uma mudança significativa que a MS está prestes a lançar mais uma vez sem pensar bem.

Conseguimos mover microsserviços do net framework para o Linux (net core) sem quase nenhum esforço das equipes prudentes. Não sei do que vocês estão falando. A Microsoft está fazendo um ótimo trabalho ao espalhar a implementação de mudanças como essa, que eram esperadas há muito tempo.

Mudanças como essa não deveriam estar acontecendo ... Então você está feliz com as mudanças significativas?

E dizer que a equipe principal do asp.net tem feito um ótimo trabalho no envio de mudanças simplesmente não é verdade.

Tenho desenvolvido com asp.net core desde o beta 3 e tenho certeza de que o processo de design de arquitetura está faltando.

Quanto ao quão bom é o núcleo do asp.net em comparação com o clássico ... Não tenho objeções, pois também acredito que seja melhor do que o clássico.

Mas só porque o núcleo do asp.net é melhor do que o clássico não significa que eles estejam fazendo um ótimo trabalho de design de arquitetura. Esses dois são tópicos completamente diferentes.

Podemos limitar esta discussão à funcionalidade JSON no .NET Core 3, por favor?

Mudanças como essa não deveriam estar acontecendo ... Então você está feliz com as mudanças significativas?

Portanto, nenhuma melhoria deve ser feita? Por que você é mesmo um programador se não quer que o software evolua e cresça e fique melhor?

@suncodefactory

Mudanças como essa não deveriam estar acontecendo ... Então você está feliz com as mudanças significativas?

Ah, vamos lá, você faz soar como "mudança de última hora" significa que você tem que descartar seu projeto e começar do zero.

Quantas alterações importantes você pode contar que existiam no ASP.NET Core 2.x / 3.0 que exigia mais do que

• Fazendo referência a um pacote diferente
• Usando um namespace diferente
• Alterar mais de 5 linhas de código
• Removendo 1-2 linhas de código (ou seja, Propriedades das classes Opções)

??

@suncodefactory

Este tópico é sobre uma mudança significativa que a MS está prestes a lançar mais uma vez sem pensar bem.

Como isso é realmente uma mudança _breaking_? As novas APIs JSON são um conjunto completamente novo de APIs que são introduzidos no .NET Core que não removem nem quebram qualquer coisa existente. Sim, você verá coisas e bibliotecas mudando para ele eventualmente, pois oferece diferentes oportunidades de otimização, mas você não é forçado a aplicar isso ao seu código.

Falando sobre ASP.NET Core em particular, embora _ “isso não tem nada a ver com este segmento específico” _, você tem a opção de continuar usando Newtonsoft.Json se depender de alguns de seus recursos mais avançados. Sim, você terá que alterar algum código para que funcione, mas não considero isso realmente uma quebra, considerando que você só precisa fazer isso se realmente quiser atualizar para a nova versão. Isso é o que é bom agora: você tem mais opções.

Se você não gostar disso por qualquer motivo, fique à vontade para usar o .NET Framework, que é um conjunto de recursos conhecidos, estáveis ​​e fixos. Isso vai ficar lá por um bom tempo, então você pode confiar totalmente nisso. Mas, por favor, pare de usar este tópico para divulgar sua agenda anti-novidades quando _ “isso não tem nada a ver com este tópico em particular” _.

Duas perguntas de um usuário EF Core.

1. System.Text.Json oferecerá suporte a referências circulares? As referências circulares podem ocorrer nos dados do EF Core, onde há links de navegação nos dois sentidos entre as classes. Json.NET lida com isso com configurações como
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. Com o surgimento de classes no estilo DDD com configuradores e construtores privados, podem System.Text.Json desserializar esses tipos de classes?

@JonPSmith IMO isso não deveria importar. Você nunca deve serializar uma entidade diretamente. Você deve serializar uma projeção. Isso evita referências circulares e não expõe todos os dados, especialmente quando você adiciona mais propriedades à entidade que podem ser confidenciais.

@JonPSmith : Imho, ambos os casos de uso são inválidos tanto do ponto de vista das melhores práticas quanto do DDD.

1. Nunca vi uma prática recomendada que recomendasse a desserialização de entidades diretamente (exceto nos exemplos de tutoriais mais simples). As referências circulares sempre têm um custo. Requer rastreamento de objetos já processados, ou seja: alocações de memória e ciclos adicionais de CPU. Mas um dos objetivos de e-mail da nova biblioteca JSON é evitar exatamente essas alocações de memória
2. Inválido também, já que você nunca serializa em um modelo de domínio, especialmente quando você obtém os dados por meio de uma solicitação da web, como uma chamada WebApi. No DDD você deve sempre trabalhar com eventos / comandos, enviar o comando para sua aplicação web, obter (e desidratar) a entidade do repositório (via mapeamento ORM ou EventSourcing), aplicar o comando, persistir.

Além disso, a nova API JSON é para cenários de alto desempenho. Para tudo o mais em que você precisa de um rico conjunto de recursos, você (e deve) ainda usar JSON.NET ou o que quer que atenda às suas necessidades.

@suncodefactory Este é o oposto de uma alteração significativa. No momento, no ASP.NET Core 2.2, o JSON.NET é usado pela estrutura e também pelo código do usuário. Isso pode causar conflitos com o uso que você faz do Newtonsoft.Json; se o ASP.NET Core 3.0 mudasse para JSON.NET 12.xe houvesse algum tipo de problema que interrompeu seu aplicativo, você teria um problema.

Por exemplo, veja Microsoft.Extensions.Configuration.Json 2.2.0 - ele depende do Newtonsoft.Json 11.0.2. Esse é um pacote de configuração; nada a ver com o tratamento de solicitações HTTP ou ASP.NET Core MVC. Ou veja Microsoft.IdentityModel.Protocols.OpenIdConnect , que o usa para lidar com Tokens da Web JSON; esse é um caminho ativo que precisa do máximo de desempenho possível. JSON.NET não é uma biblioteca lenta por nenhum padrão, mas atinge um equilíbrio entre desempenho, riqueza de recursos e suporte para uma grande variedade de cenários de usuário. A nova biblioteca JSON da Microsoft não precisa fazer isso, porque JSON.NET existe. Portanto, ele pode se concentrar em lidar com o básico absoluto com desempenho máximo.

.NET sempre teve sua própria solução de serialização JSON em System.Runtime.Serialization.Json , mas no mundo de alto desempenho do .NET Core ela não é muito boa. Eu certamente não gostaria que ele fosse invocado para verificar as credenciais em cada solicitação recebida. Uma nova biblioteca JSON, com manipulação de dados UTF-8 moderna e alocações mínimas, é muito bem-vinda.

Você ainda poderá fazer referência a Newtonsoft.Json em seu aplicativo e continuar a usá-lo como pipeline de desserialização / serialização para dados de solicitação / resposta como antes. E a partir de agora, você poderá fazer isso sem se preocupar com a versão da qual o framework Core depende. É uma vitória para todos.

Obrigado @ phillip-haydon e @TsengSR por seus pensamentos. Eu estava perguntando se esses recursos seriam suportados e você diz que não é, que entende e aceita. Vou continuar a usar Json.NET para o caso em que preciso serializar / desserializar classes EF Core.

POR FALAR NISSO. Eu tenho um motivo válido para serializar / desserializar classes de entidade EF Core de estilos DDD. Eu tenho uma biblioteca que contém um recurso que chamo de Seed from Production, que permite aos desenvolvedores tirar um instantâneo dos dados de um banco de dados de produção, tornar anônimos quaisquer dados privados e, em seguida, propagar um novo banco de dados com o instantâneo.

Eu precisava desse recurso para um em meus clientes e, em vez de escrever apenas para eles, eu o construí em minha biblioteca de código aberto EfCore.TestSupport para que outros possam usá-lo (e meu cliente não teve que me pagar por isso).

Existe um plano para apoiar [DataContract] , [DataMember] e amigos?

Hoje esta é uma maneira de definir como os tipos devem serializar / desserializar (por exemplo, o nome do campo) de uma forma que não traga uma dependência para nenhuma biblioteca de serialização para o projeto que o usa.

O JsonNamingPolicy atual leva apenas uma string, então não há como inspecionar os atributos do membro.

Oi.
Acabamos de tentar mudar nossos microsserviços para DotNet core 3 preview 6 e não conseguimos desserializar nossos tipos de referência imutáveis: classe com propriedades imutáveis ​​(sem setters) e apenas um construtor para definir todas as propriedades. Json.net lida corretamente com essas classes.
Isso é um problema da API System.Text.Json necessária ou é um plano para suportá-la?
Obrigado por suas respostas

@agjini Veja https://github.com/dotnet/corefx/issues/38569

Obrigado @khellang.
O suporte está planejado de fato, mas não para o lançamento 3.0.
Parece ser possível continuar usando Json.net com DotNet core 3, mas não sei como fazer (adicionar referência de pacote não é suficiente). Existe uma maneira de fazer isso?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

Obrigado pela ajuda pessoal.
Funciona !
Perdi o guia de migração, onde tudo é explicado:

https://docs.microsoft.com/fr-fr/aspnet/core/migration/22-to-30?view=aspnetcore-2.2&tabs=visual-studio

IMO json.net está pela metade e torná-lo o padrão (ou seja, para o signalr) que quebra o código existente foi prematuro.

Por outro lado, migrar do .NET Core 2.2 para 3.0 é uma atualização de versão principal e, mesmo que a equipe do .NET Core não siga estritamente o controle de versão semântico, eu esperaria que alguma coisa quebrasse durante a atualização de uma versão para outra sem alterações explícitas (como adicionar explicitamente a biblioteca da Newtonsoft no pipeline)

O fechamento, visto que isso é um anúncio e não um problema

Embora a comunidade tenha muitas vozes contra a melhoria, como uma nova estrutura de alto desempenho, a velocidade ruim é inaceitável.

Sei que já foi dito, mas também gostaria de acrescentar meu desejo.

Seria realmente incrível se pudéssemos ter objetos imutáveis. Eu sei que é possível adicionar Json.NET ao MVC-Pipeline, mas no meu caso meus testes estão todos falhando porque estou usando ReadAsAsync<> que agora está implementado em algum lugar em uma dependência de par de Microsoft.AspNet.WebApi.Client e isso depende de System.Text.Json

Fornecemos a biblioteca .NET Standard Class aos clientes para que eles possam usar nossa biblioteca para trabalhar em qualquer plataforma que ofereça suporte ao .NET Standard. Precisamos usar System.Text.Json em nossa biblioteca de classes. Qual será o plano para oferecer suporte a System.Text.Json no .NET Standard?

@alsami

Seria realmente incrível se pudéssemos ter objetos imutáveis.

Você só precisa da capacidade de impedir que outros sofra mutação ou também precisa da capacidade de criar novas instâncias com peças sendo substituídas de forma inteligente (como coleções imutáveis ​​e Roslyn)? Se você precisar do primeiro, nós o ajudamos com as próximas JsonDocument DOM APIs.

@ mwoo-o

Qual será o plano para oferecer suporte a System.Text.Json no .NET Standard?

Está disponível como um pacote NuGet para .NET Standard 2.0: System.Text.Json .

@terrajobst

Obrigado. Quando este System.Text.Json será incluído no .NET Standard SDK?
O padrão .NET 3.0 (ou alguma outra versão posterior) incluirá o pacote System.Text.Json? Isso acontecerá na versão de produção do .NET Core 3.0 SDK?

@terrajobst

Existem planos para fazer o método de desserialização funcionar com o PipeReader? Ou adicione o método Patch que pode ser usado em cenários de streaming onde não temos todos os dados quando começamos a desserialização.

Aqui está uma versão simplificada da API proposta:

private async ValueTask<T> Deserialize<T>(PipeReader reader, CancellationToken cancellationToken) 
    where T: new()
{
    T model = new T();
    while (!cancellationToken.IsCancellationRequested)
    {
        ReadResult readResult = await reader.ReadAsync(cancellationToken);
        ReadOnlySequence<byte> buffer = readResult.Buffer;

        if (readResult.IsCanceled) break;
        if (buffer.IsEmpty && readResult.IsCompleted) break;

        SequencePosition consumed = JsonSerializer.Patch(model, buffer, readResult.IsCompleted);
        reader.AdvanceTo(consumed, buffer.End);               
    }

    return model;
}

public SequencePosition Patch<T>(T model, ReadOnlySequence<byte> jsonData, bool isFinalBlock, JsonSerializerOptions options = null)
{
      ...            
}

@terrajobst

capacidade de evitar que outros o transformem

Só isso atualmente. É realmente apenas para 'objetos de transferência de dados'. Boas notícias!

@ mwoo-o

Obrigado. Quando este System.Text.Json será incluído no .NET Standard SDK?
O padrão .NET 3.0 (ou alguma outra versão posterior) incluirá o pacote System.Text.Json? Isso acontecerá na versão de produção do .NET Core 3.0 SDK?

Não há SDK do .NET Standard. .NET Standard é uma superfície API, disponível em todas as plataformas suportadas. Você pode enviar System.Text.Json em qualquer aplicativo que execute as plataformas suportadas pelo .NET Standard, consulte Suporte à implementação .NET .

@TsengSR

Não há SDK do .NET Standard. .NET Standard é uma superfície API, disponível em todas as plataformas suportadas.

Bem, existe um tipo de projeto que permite que você use as APIs. Acho que @ mwoo-o está perguntando se temos planos de adicionar System.Text.Json ao .NET Standard. A resposta é não. Certo, agora estamos planejando deixar isso para ser um pacote NuGet.

É terrível. Poucas funções a serem aplicadas no projeto.