Runtime: El futuro de JSON en .NET Core 3.0

Esto es genial. Estoy a favor de un análisis json más rápido y con menos asignación.

¿Habrá una discusión sobre las características de json.net que admitirán las nuevas apis json? Si es así, creo que las dos características principales que me vienen a la mente serían el cambio de nombre / propiedades de revestimiento e ignorar las propiedades nulas.

¿Habrá una discusión sobre las características de json.net que admitirán las nuevas apis json?

Si. Hemos pensado desde el principio que migraremos a CoreFx. Será una característica diseñada y construida al aire libre como de costumbre. Además, me comuniqué con los autores de muchas de las bibliotecas JSON populares y los invité a revisar los primeros borradores de este anuncio. Mi esperanza es que podamos trabajar juntos para crear un componente JSON sólido para la plataforma y al mismo tiempo mantener el ecosistema en la parte superior (como ASP.NET Core) enchufable para permitir otros. Al final, diferentes consumidores tendrán diferentes objetivos y poder conectar una biblioteca diferente significa que puede obtener la máxima flexibilidad para elegir el componente que tiene el mejor costo / beneficio para su aplicación.

Hola @terrajobst. ¿Aparecerá el nuevo JSON como una superficie de API estándar de red, o simplemente se integrará en Core por ahora?

Hola @terrajobst. ¿Aparecerá el nuevo JSON como una superficie de API estándar de red, o simplemente se integrará en Core por ahora?

Sí, la pregunta es qué tren de lanzamiento puede tomar. 2.1 podría ser demasiado pronto.

Por lo tanto, se planea que los bits de análisis JSON horneados en el marco estén disponibles cuando v3.0 vaya a RTM o solo se completará la integración Apis en ASP.NET Core (con solo una implementación: JSON.NET) que se podrá intercambiar en un ¿fecha posterior?

El plan para 3.0 es el siguiente:

1. API JSON de alto rendimiento integradas. Lector / escritor de bajo nivel, un lector / escritor basado en Stream y un serializador.
2. ASP.NET Core se puede conectar al componente JSON.

Hay una pregunta abierta sobre qué utilizarán las plantillas para ASP.NET en 3.0. Dependiendo de la fidelidad que podamos proporcionar con 3.0, podríamos hacer que extraigan el paquete de integración Json.NET. Sin embargo, el objetivo es ofrecer suficiente fidelidad y paridad para depender solo de los integrados de forma predeterminada.

Gracias, eso ayuda a aclarar las cosas. 👍

¡Y algunas preguntas adicionales!

Si se usa un paquete de integración, ¿se usará en toda la canalización de ASP.NET Core o solo en algunos lugares?
Supongo que Kestrel siempre usará los lectores / escritores internos.

¿Sería la ergonomía de Api:

• Proporcione una integración solo cuando desee mejorar el conjunto de funciones integradas.
• Suministre un paquete de integración siempre, pero uno estaría incorporado, integrando los lectores / escritores de bajo nivel en una funcionalidad de nivel superior.

Suponiendo que este nuevo analizador se usará para todas las cosas JSON incorporadas como appSettings.json , ¿podría presentar una solicitud anticipada para que los comentarios sean compatibles?

Gracias.

¡Esta es una gran noticia! Pregunta rápida: ¿De qué paquetes dependerá esta biblioteca?

¿Por qué reinventar una rueda probada por los clientes de producción? Si hay un problema con Json.Net, simplemente envíe un PR ya que es de código abierto.

Supongo que el problema con Json.NET es que no es propiedad de Microsoft, por lo que debe ser reemplazado. Oh, pero ya existe uno en System.Runtime.Serialization, llamado DataContractJsonSerializer. ¿Puedes usar eso, o es tan divertido codificar nuevas API, DIY, que no se puede evitar?

La razón por la que no estoy muy contento con esto es que Json.Net ya admite casos extremos como, por ejemplo, F # Discriminated Unions. No particularmente bien, pero a un nivel en el que los desarrolladores pueden vivir con eso. En cambio, cualquier API nueva generalmente olvida cualquier otra cosa que no sea el caso de uso de un sitio web ASP.NET.

@markrendle Hay una configuración de suscripción en JsonReader (trabajo en progreso) para permitir comentarios. Es probable que el sistema de configuración habilite esa configuración de forma predeterminada.

@Thorium ¿De verdad leíste el OP? Explica por qué no JSON.NET, y que JSON.NET seguirá siendo compatible oficialmente con un paquete de complementos.

@JamesNK 😄

@Thorium Json.NET no va a desaparecer. No estás perdiendo nada. Esta es otra opción para escenarios simples y de alto rendimiento.

@Thorium Json.NET no va a desaparecer. No estás perdiendo nada. Esta es otra opción para escenarios simples y de alto rendimiento.

¿Cómo se generará el Json para que sea compatible con versiones anteriores?

Por ejemplo, estoy usando SignalR que usa Json.NET en segundo plano. Ahora, ¿mis uniones discriminadas de F # se serializarán en estructuras similares para no tener problemas con el nuevo Azure Signalr Service (backplane) que arroja excepciones en tiempo de ejecución debido a la serialización de las estructuras de manera diferente a la biblioteca SignalR actual de mi servidor?

Espero que otros aprendan las nuevas API rápidamente. Mirándote, @AzureCosmosDB ;-)

¿Está planeando incluir una clase como JObject y soporte para dinámica o esto está fuera del alcance de esta función?

Recomiendo echar un vistazo a una de estas bibliotecas:

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

esta podría ser una muy buena forma de inspirarte.

¿Se utilizará internamente en DataContractJsonSerializer este nuevo lector / escritor?

Me comuniqué con los autores de muchas de las bibliotecas JSON más populares y los invité a revisar los primeros borradores de este anuncio. Mi esperanza es que podamos trabajar juntos para crear un componente JSON sólido para la plataforma y al mismo tiempo mantener el ecosistema en la parte superior (como ASP.NET Core) enchufable para permitir otros.

¿Hay alguna razón por la cual la segunda biblioteca JSON más popular después de JSON.NET, ServiceStack.Text, que ya se ha refactorizado para construirse en Span?API ha sido excluido? Los serializadores ServiceStack.Text son los que se utilizan para alimentar ServiceStack, que es uno de los "frameworks web alternativos compatibles con .NET Core" más populares que admite la ejecución en más plataformas en .NET . Tengo curiosidad sobre a qué "ecosistema" se está refiriendo y con el que espera "trabajar juntos" aquí. Obviamente, me interesaría en qué tan compatibles terminan siendo estas API "conectables" o si esto termina siendo otra área en la que la adopción e integración de nuevas bibliotecas de MS termina matando el ecosistema que está reemplazando.

Puede valer la pena revisar el alto rendimiento con licencia del MIT https://github.com/neuecc/Utf8Json

Esto es definitivamente lo que necesitamos ... mi sugerencia para el nombre de la clase principal, simplemente use " Json ".

@terrajobst Me preguntaba cuándo sucedería esto ...

Siempre me preguntaba por qué JSON.Net se agregó como una dependencia directa en lugar de una abstracción (incluso considerando que es el paquete JSON de facto para el ecosistema .Net).

Sin embargo, creo que agregar una abstracción solo para JSON es de alguna manera un lanzamiento en sus pies. Creo que una abstracción _serializer_ como la que tenemos en Orleans IExternalSerializer en forma de Microsoft.Extensions.Serialization o algo sería más efectivo ...

¿Hay alguna razón en particular por la que make sea solo JSON? Veo otros casos en los que la gente puede conectar otros tipos de serializadores ...

@galvesribeiro ¿ Algo como IOutputFormatter / IInputFormatter ?

@ yaakov-h no estaba al tanto de esos ... ¿Lo eran?

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

Okey ... tiene sentido ahora. Entonces, ¿dónde entran en juego estas _new_ abstracciones exclusivas de JSON?

La decisión de iniciar esta empresa también es un testimonio de la ineficiencia de System.String (UTF-16 String).
Creo que los nuevos ganchos JSON que abstraerán todo el manejo de json entre asp.net y una biblioteca json se verían significativamente mejor si abordas la tarea de crear un tipo BaseType de cadena utf-8 primero.
-> Tal vez cree un System.Utf8String

Sí ... Recuerdo que @migueldeicaza dijo hace un tiempo que algún día hará que .Net use utf8 strings 😄

@ jges42 @galvesribeiro La propuesta para agregar Utf8String es https://github.com/dotnet/corefx/issues/30503. Parece que también está planeado para .Net Core 3.0.

¿Estas nuevas API JSON tendrán rutas de código dedicadas para Utf8String y char / string , o la optimización implica cambiar el status quo, de modo que todo lo que no sea UTF-8? tendrá que transcodificarse a él en su lugar? (Esto no implica necesariamente un costo enorme, ya que casi nada es UCS-2 UTF-16 nativo de string y aún debe ser adaptado / contabilizado, solo estoy tratando de hacerme una idea del Superficie de API. Hacer esto para permitir que Kestrel sea más eficiente es razonable; solo espero que el diseño considere más clientes que Kestrel).

@galvesribeiro
De hecho, creo que planteas un buen punto. Creo que crear un marco de serialización eficiente y un decodificador / codificador Json eficiente son dos tipos de problemas. Sé que hay algunas formas de marcar una estructura como serializable, pero nunca la he visto utilizada para ninguna serialización Json.

El proyecto Serde de Rust tiene en realidad un buen concepto al dividir el problema en 2 problemas:

1. Serializar / Deserializar (Rasgos similares a las interfaces en C #) lo que significa que cualquier tipo que herede de esta interfaz puede serializarse / deserializarse
2. Serializer / Deserializer es la implementación específica del formato.

Un tipo puede implementar Serialize / Deserialize a mano o mediante una macro (que podría verse como una forma de complemento de compilador) que genera el código necesario para implementar esos rasgos. Si un tipo contiene un tipo hijo que no implementa esos rasgos, incluso lo advertirá en el momento de la compilación. Es un concepto agradable en general porque significa que puede escribir algunos objetos de datos y (des) serializarlo para cualquier formato compatible. Escribir un formato es mucho más fácil de esta manera.

No creo que todas las formas de Serde funcionen para C # porque realmente no ofrece ningún tipo de atributo específico que pueda ser importante para algunas estructuras de datos. Por lo tanto, se debe trabajar un poco para lograrlo. También considerar la compilación de AoT será muy importante para algunos proyectos (WASM). También debería funcionar bien con ella.

Aquí hay un enlace a los documentos de Serde para que sea más claro (haga clic en los 4 rasgos inferiores para ver el concepto):
https://docs.serde.rs

@mythz La licencia de ServiceStack.Text es AGPL con alguna excepción de FOSS; probablemente evitaría que la gente lo use en software propietario. También creo que se requiere autorización legal para que los empleados de Microsoft incluso lo toquen, y cualquier empleado que haya mirado la fuente podría tener prohibido trabajar en cualquier otra biblioteca JSON o tecnología relacionada.

@ poizan42 ServiceStack.Text tiene doble licencia con OSS / licencias comerciales libres para usar tanto en OSS como en proyectos comerciales de código cerrado. Pero las licencias del código fuente son irrelevantes ya que MS está desarrollando su propia implementación.

La afirmación fue que MS estaba colaborando con el "ecosistema" para desarrollar API de serializador JSON "conectables", si ServiceStack, que ha estado en desarrollo activo durante casi una década, es una de las pocas suites de software .NET independientes que ha logrado mantener su propia comunidad saludable independiente fuera de MS durante su vida, que mantiene el segundo serializador JSON más popular después de JSON.NET y lo que parece ser el segundo marco web desarrollado activamente más popular (fuera de MS), que se ejecuta en más plataformas que cualquier MS marco web no se considera parte del "ecosistema" que se ve afectado principalmente por estos cambios, tengo curiosidad a qué "ecosistema" se refieren y por qué estamos siendo excluidos y cuántos otros están siendo excluidos porque son no se considera parte del "ecosistema".

No entiendo todo este resentimiento. Asp.net te obligó a usar una versión específica de json.net. Lo están cambiando para que pueda elegir el analizador JSON que desee (o mezclarlo), y hay uno predeterminado OOB. ServiceStack debería estar contento con este cambio y monitorear y proporcionar comentarios sobre este desarrollo, en lugar de quejarse de cómo se había pasado por alto, lo que rara vez es una forma eficaz de fomentar un buen espíritu comunitario. Conozco personalmente a muchos de los miembros del equipo .net y estoy seguro de que no pretendieron ninguna malicia. Todos ellos son grandes defensores del OSS y el trabajo comunitario.
Personalmente, cualquier licencia derivada de la GPL sería un gran no automático para mí. Apache o MIT para mí y mis clientes o seguiremos adelante. Sin licencias duales misteriosas.

Asp.net te obligó a usar una versión específica de json.net

No. ¿Cómo es eso?

No entiendo todo este resentimiento.

¡Secundado!

Personalmente, estoy feliz de que finalmente podamos usar el serializador de nuestra elección sin tener que descargar JSON.Net solo para no usarlo, pero aún así necesitamos enviarlo porque ASP.Net tiene una referencia estricta a la biblioteca.

(Enchufe desvergonzado: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

No entiendo todo este resentimiento.

Porque no has leído ni entendido mis comentarios. Trate de responder directamente a mis comentarios (es decir, use la función de citas) en lugar de inventar su propia narrativa.

Lo están cambiando para que pueda elegir el analizador JSON que desee (o mezclarlo)

Entonces, como una "mezcla" mágica, automáticamente elegirán la API más óptima y las opciones de conexión que los serializadores .NET existentes podrán conectar directamente y mezclar en sus opciones de personalización internas, siendo el formato de cable exactamente el ¿Lo mismo y todo va a funcionar en todos los serializadores? En ese caso, tiene razón, no se necesitan pruebas de colaboración o integración antes de que se solidifiquen las API. O tal vez las implementaciones de serializador tienen más matices con varias diferencias y opiniones y todo no solo va a funcionar, no todas las opciones de personalización se implementarán exactamente, el formato de cable no será el mismo y no será posible lograrlo. perfecta interoperabilidad entre diferentes implementaciones. La "capacidad de conexión" que está pasando por alto hace una gran diferencia que puede determinar la cantidad de reescritura que tendremos que hacer y si será posible o no admitir la implementación existente y esta nueva.

ServiceStack debería estar contento con este cambio y monitorear y proporcionar comentarios sobre este desarrollo,

Lo cual no hemos tenido la oportunidad de hacer (o aún sabemos cómo hacerlo), pero gracias por dejarme saber cómo debería sentirme. Preferiría evaluar la funcionalidad, la interoperabilidad y la compatibilidad de la biblioteca antes de poder evaluar la solidez de cada una. Tal vez sea genial y será fácil admitir ambas implementaciones, pero según la experiencia, la interoperación con diferentes implementaciones de serializador está plagada de incompatibilidades y casos de esquina y dependencia de diferentes implementaciones y características específicas de serialización. Mi predicción es que la interoperabilidad entre JSON.NET y el impl predeterminado será excelente, ya que ese es su objetivo de diseño y lo que se está probando, pero otros serializadores no serán tan afortunados.

en lugar de quejarse de cómo se había pasado por alto, lo que rara vez es una forma eficaz de fomentar un buen espíritu comunitario.

Estoy desafiando su afirmación de que han desarrollado esto en colaboración con el "ecosistema", .NET ha tenido un historial de matar el ecosistema existente cada vez que agrupan una biblioteca "predeterminada", lo que también espero que suceda. aquí (estoy luchando por recordar un momento en el que agrupar un valor predeterminado alguna vez ayudó al ecosistema). Pero independientemente, necesitamos desarrollar una integración perfecta con lo que sea que estén lanzando y al que me gustaría poder tener acceso y entrada antes de que se congelen las API. Pero está bien, no espero que le importe cómo afecta a los marcos / bibliotecas existentes que necesitan admitir implementaciones existentes y futuras, es probable que solo le preocupe si JSON.NET sigue siendo compatible o no porque eso es todo lo que lo afecta, pero intente aferrarse a sus suposiciones y díganos cómo deberíamos sentirnos al absorber cambios disruptivos como este.

Estoy luchando por recordar un momento en el que agrupar un valor predeterminado alguna vez ayudó al ecosistema

¡Oh vamos!

(En el resto estoy mayoritariamente de acuerdo con tus sentimientos)

@mythz Me sorprende que esto esté causando problemas, ya que hoy incluimos otra biblioteca JSON de terceros en el marco. Solo hay un puñado de lugares donde horneamos JSON y la mayoría de ellos tienen un modelo de proveedor que los usuarios reemplazarían razonablemente (como los formateadores MVC).

Mi predicción es que la interoperabilidad entre JSON.NET y el impl predeterminado será excelente, ya que ese es su objetivo de diseño y lo que se está probando, pero otros serializadores no serán tan afortunados.

Ya puedo decirles que lo que enviaremos no admitirá la gama de funciones que admite JSON.NET. Entonces eso ya no es cierto y, de hecho, esperamos que sea menos capaz en algunos casos (debido a razones de rendimiento y alcance).

La capacidad de conexión ya existe en su mayoría en la actualidad y tenemos implementaciones JSON.NET predeterminadas en todas partes. Esto solo está cambiando ese valor predeterminado para que sea el nuevo serializador JSON en su lugar ...

@abatishchev

Realmente no puedo recordar ninguno, ¿cuándo la incorporación o adopción de una implementación predeterminada en su marco (o proyectos) base benefició al ecosistema circundante existente? Cada vez que lo he visto empaquetado, por ejemplo, NuGet, MVC, ORM, pruebas unitarias, API web, etc., solo ha tenido un efecto perjudicial, tomando efectivamente el oxígeno y la motivación para competir dentro de ese espacio.

Hay momentos como en los que bibliotecas de la competencia como ASP.NET Ajax no han podido competir y terminaron abandonándola y adoptando jQuery, pero no recuerdo un momento en el que haya ayudado. Nota: Esta es solo mi observación de seguir de cerca .NET después de varios años, tal vez haya ejemplos y me gustaría saber algunos. pero desde mi punto de vista, los efectos de los valores predeterminados de MS tienen un efecto perjudicial en el ecosistema existente de funcionalidad que está reemplazando.

Los beneficios de

Pero no inundemos y nos quedemos con el tema. ¡Salud!

@davidfowl Esto solo está cambiando ese valor predeterminado para que sea el nuevo serializador JSON en su lugar ...

Me gustaría proponer que no haya un serializador predeterminado y requiera que se descargue una implementación. Si debe haber un valor predeterminado, ¿se incluirá en el marco o en alguna biblioteca separada (como es el caso actualmente)?

Me gustaría proponer que no haya un serializador predeterminado y requiera que se descargue una implementación. Si debe haber un valor predeterminado, ¿se incluirá en el marco o en alguna biblioteca separada (como es el caso actualmente)?

Eso es irrazonable ya que la experiencia será insatisfactoria. Todas las plataformas modernas tienen JSON integrado.

@davidfowl No está causando problemas ahora porque no se lanzó, pero aún debemos evaluar la interrupción y el alcance del trabajo que causará. ¿Cuánto esfuerzo requerirá para admitirlo sin problemas, podremos aplicar personalizaciones al nuevo impl para admitir nuestro comportamiento existente, podremos admitir el nuevo modelo de personalización y las API, podremos personalizar nuestro serializador para admitir La configuración predeterminada / formato de cable permitirá que las nuevas API admitan tanto .NET Core como .NET Framework; aunque está claro que ASP.NET Core 3 abandonará .NET Framework, no está claro si las nuevas API se utilizarán. NET Core solo los tipos que nos prohibirán continuar admitiendo tanto .NET Core como .NET Framework.

Ya puedo decirles que lo que enviaremos no admitirá la gama de funciones que admite JSON.NET. Entonces eso ya no es cierto y, de hecho, esperamos que sea menos capaz en algunos casos (debido a razones de rendimiento y alcance).

Solo espero que admita un subconjunto de características JSON.NET, por ejemplo, ¿JSON.NET admitirá el formato de cable predeterminado? (Asumo que sí). ¿Adoptará la nueva implícita los formatos de serialización JSON.NET siempre que sea posible (también asumiendo que sí)?

¿Cuánto esfuerzo requerirá para admitirlo sin problemas, podremos aplicar personalizaciones al nuevo impl para admitir nuestro comportamiento existente, podremos admitir el nuevo modelo de personalización y las API, podremos personalizar nuestro serializador para admitir La configuración predeterminada / formato de cable permitirá que las nuevas API admitan tanto .NET Core como .NET Framework.

@mythz No estoy siguiendo algo de esto. Estoy tratando de averiguar cuánto es esto de discutir las API existentes en comparación con cómo se consumirán. ¿Quizás podríamos mirar algunos escenarios concretos?

@mythz, la única preocupación real que veo para servicestack sería si esta nueva api no es compatible con .net framework classic, de esa manera, servicestack no podrá admitir tanto .net core como .net classic, como paquetes de cliente dependiendo de esas bibliotecas no estará disponible en .net framework full. ¿Es ésa tu preocupación? Lo pregunto porque su preocupación como ejemplo concreto no está clara.

Además, esta es una propuesta en su etapa inicial y el objetivo que quiere lograr parece bastante prometedor. La crítica constructiva siempre es buena para cualquier proyecto de oss.

Los beneficios de

Por ecosistema me refiero al ecosistema / comunidades de bibliotecas .NET circundantes (que presumiblemente también es el "ecosistema" en el que se refiere el OP) al que reemplaza y que también diría que los usuarios de .NET también se benefician de un ecosistema saludable con una variedad de opciones y más competencia (como es el rasgo de ecosistemas más saludables como Python, Java, Node, Ruby, PHP, etc.).

EF es el mejor ORM del mundo .NET

Poco después del lanzamiento de EF, rápidamente tomó la participación de mercado mayoritaria de ORM, mientras que era más de 6 veces más lento que NHibernate y, al mismo tiempo, admitía menos funciones, extracto de mi entrevista de InfoQ de 2012 :

Su último intento en una capa de acceso a datos de ORM en Entity Framework también ha impactado negativamente en la antes próspera comunidad de ORM NHibernate. A pesar de ser varias veces más lento que cualquier otro ORM .NET de código abierto , EF ha logrado atraer más descargas que todos los demás ORM combinados.

Tenga en cuenta que esto era anterior a .NET Core, donde el rendimiento ahora es una prioridad máxima, pero es un ejemplo histórico del efecto perjudicial que tienen los valores predeterminados de MS en los ecosistemas / comunidades existentes. En mi opinión, es bastante aceptado lo que les sucede a las comunidades existentes cuando MS introduce valores predeterminados, por lo que ha habido un retroceso reciente para revertir los valores predeterminados de envío que compiten con IdentityServer y AutoMapper.

y MSTest fue mejor que NUnit en su día.

En mi opinión, nunca lo fue (y el soporte R # de NUnit siempre ha sido excelente AFAICR) y el hecho de que no pudiéramos ejecutarlo multiplataforma en Mono significaba que las bibliotecas que admitían multiplataforma en Mono (antes de .NET Core) no podían usar eso.

Pero no inundemos y nos quedemos con el tema. ¡Salud!

Tampoco quiero secuestrar este hilo en esto tampoco, pero necesitaba decir por qué no estoy de acuerdo con sus puntos.

En relación con esto, la razón principal ahora para usar un serializador diferente a JSON.NET es el rendimiento y, dado el motivo de este nuevo serializador predeterminado, es el rendimiento. Dado que la mayoría de las personas solo usan valores predeterminados, espero que esto tenga el impacto más notable en el recurso compartido de JSON.NET, mientras que la razón principal para usar un serializador alternativo ya no debería existir con esta implicación más rápida. Básicamente, también veo que esto tiene un efecto perjudicial en el ecosistema (biblioteca) existente. En mi opinión, un ecosistema más débil de JSON libs es un negativo neto para .NET (no es algo que la mayoría de los consumidores verán, solo usarán los valores predeterminados y se olvidarán de las otras opciones), pero esa no es mi principal preocupación.

@davidfowl @ shahid-pk

A pesar de esto, realmente hubiera preferido que esto existiera hace 8 años, ya que la razón principal para desarrollar ServiceStack.Text fue porque los serializadores JSON de .NET Framework eran extremadamente lentos. Pero después de todo este tiempo, SS.Text se ha ampliado con una serie de características en todas nuestras bibliotecas, por ejemplo, personalizaciones para admitir diferentes idiomas ServiceStack Support , diferentes opciones de personalización JSON en ServiceStack , soporte JSON en ServiceStack Templates , soporte de blob JSON de tipo complejo en ServiceStack .Redis, etc.

Así que ahora estoy enfocado en evaluar cuál será el impacto, cómo se verán las nuevas API y las opciones de conexión, si podemos adaptar las características existentes a ellas, seremos capaces de adoptar como serializador JSON en SS .NET Core Apps. (qué se romperá), ServiceStack.Text podrá admitir la nueva API, podremos admitir .NET v4.5, podrá personalizarlo para admitir formatos de cable de implementaciones existentes, etc. Básicamente, no tengo idea del impacto de esto o de cuál será la estrategia en el futuro, ya que todavía no he tenido la oportunidad de usar o ver nada. Sabré más respuestas cuando tenga la oportunidad de usarlo y, obviamente, me gustaría tener la oportunidad de probar la integración y proporcionar comentarios y proponer cambios antes de que se congelen las API.

@mythz

¿Hay alguna razón por la que se haya excluido la segunda biblioteca JSON más popular después de JSON.NET, ServiceStack.Text, que ya se ha refactorizado para que se compile

La omisión no fue intencional. Hemos buscado activamente y trabajado con autores de bibliotecas JSON como parte del repositorio de CoreFxLab y uno de nuestros desarrolladores comenzó a comparar nuestros trabajos con los de ellos. Creo que la lista se completó inicialmente mediante el uso de

Tengo curiosidad sobre a qué "ecosistema" se está refiriendo y con el que espera "trabajar juntos" aquí.

El ecosistema .NET y en particular las partes interesadas en el procesamiento JSON.

Obviamente, me interesaría en qué tan compatibles terminan siendo estas API "conectables" o si esto termina siendo otra área en la que la adopción e integración de nuevas bibliotecas de MS termina matando el ecosistema que está reemplazando.

El propósito de los puntos de extensión de ASP.NET Core planificados es permitir a los clientes reemplazar el componente JSON integrado con cualquier biblioteca JSON que deseen. Por supuesto, ASP.NET siempre se ha enviado con "baterías incluidas", es decir, una experiencia predeterminada razonable. En el pasado, esto ha sido Json.NET y, en el futuro, es un componente proporcionado por la plataforma. Dado que Json.NET estaba algo integrado en ASP.NET, el nuevo plan parece ser mejor para personas como usted; así que no estoy del todo seguro de qué parte de nuestro plan cree que es una amenaza.

Hay una pregunta abierta sobre qué utilizarán las plantillas para ASP.NET en 3.0.

¿No es hora de que las plantillas sean modulares? Como tomar vue.js por ejemplo.

Crear una nueva aplicación vue te permite elegir las cosas que quieras. ¿Por qué no se puede hacer algo similar para asp.net en lugar de crear 500 plantillas para adaptarse a todos los escenarios?

Aquí hay un ejemplo concreto de una característica en .ASP NET Core 2.2 donde los formateadores de entrada / salida JSON que no sean JSON.NET enfrentarán problemas y cómo una solución desacoplada podría ayudar:
La función ProblemDetails , que permite una respuesta de error compatible con 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);

El código anterior está anotado con atributos específicos de JSON.NET, incluido un atributo de respaldo específico [JsonExtensionData] , todas las propiedades JSON desconocidas se deserializan en este diccionario y el contenido de este diccionario se serializa en la estructura JSON normal.

Cualquier formateador de entrada / salida JSON alternativo ahora necesita manejar estos atributos específicos de JSON.NET para poder serializar / deserializar correctamente este tipo o encontrar una forma diferente, es decir, recurrir a JSON.NET para estos tipos.

Ahora, si tenemos una especificación bien definida de características que un Input / OutputFormatter para JSON necesita ser compatible con 3.0, el problema anterior no existe ya que, es decir, estos atributos podrían vivir en un paquete Microsoft.Extension ... y cada formateador JSON personalizado podría utilizarlos para implementar esta funcionalidad para que sea compatible.

En cuanto a mi conocimiento, solo hay algunas instancias de código fuente "oficial" en ASP.NET Core que están anotadas por atributos JSON.NET, pero también he visto bibliotecas de terceros que usan atributos específicos de JSON.NET (generalmente para especificar el nombre del atributo a través de [JsonProperty("name")]

FWIW, de eso se trata https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Creo que respondió antes de leer mi comentario anterior que, en mi opinión, aclara más mis preocupaciones.

Estamos buscando activamente comentarios adicionales.

¿Dónde? ¿Existe una propuesta / documento de API, se ha creado una API, bajo qué repositorio se está desarrollando?

Creo que respondió antes de leer mi comentario anterior que, en mi opinión, aclara más mis preocupaciones.

Lo he leído, pero parece que te opones a tener un valor predeterminado, lo cual, como explicó

¿Dónde? ¿Existe una propuesta / documento de API, se ha creado una API, bajo qué repositorio se está desarrollando?

Deliberadamente, todavía no hemos realizado ningún diseño de codificación / API en .NET Core porque queríamos publicar este anuncio primero. No queríamos que la gente leyera las hojas de té sin proporcionar el contexto que proporciona este anuncio. En otras palabras, estad atentos, publicaremos API y código pronto.

@terrajobst Impresión completa para la publicación que

1. La decisión de realizar cambios está hecha.

En el futuro, planeamos realizar algunos cambios en nuestro soporte JSON:

1. Se realiza un diseño preliminar
   Necesitamos API JSON de alto rendimiento.
   Elimine la dependencia de ASP.NET Core a Json.NET.
   Proporcione un paquete de integración ASP.NET Core para Json.NET.

Todo esto significa que se toma la dirección. Todo lo que se le pide al "ecosistema" es encontrar puntos de dolor obvios que la EM no podría explicar de manera realista.

La omisión de ServiceStack y discutirlo como una biblioteca .NET de clase secundaria es ridículo. Incluso yo solo en las bibliotecas enviadas por MS, eso no significa que no conozca las alternativas.

No tengo ningún problema con que la EM tome decisiones, pero si se expresó directamente y no se cubrió con "comentarios de la comunidad" sobre decisiones ya tomadas.

Esa es mi impresion

@terrajobst

Lo he leído, pero parece que te opones a tener algún defecto.

Nunca sugerí eso, JSON.NET ya era el predeterminado antes de esto. Lo expliqué con más detalle anteriormente, pero para reiterar, esto está posicionado para asumir el control predeterminado y convertirse en el nuevo estándar de facto donde efectivamente .NET Core solo tendrá 2 serializadores JSON en su futuro: este nuevo predeterminado de alto rendimiento de facto y JSON. NET para funciones personalizadas. Otros serializadores JSON se convertirán en un nicho, por ejemplo, se agregarán características únicas para admitir diferentes escenarios.

Deliberadamente no hemos realizado ningún diseño de codificación / API .NET Core porque queríamos recibir este anuncio primero.

De acuerdo, no es posible que ningún "forastero" sepa qué tan bien la conectabilidad, la extensibilidad o la interoperabilidad
será todavía.

No queríamos que la gente leyera las hojas de té sin proporcionar el contexto que proporciona este anuncio. En otras palabras, estad atentos, publicaremos API y código pronto.

Entonces, ¿se desarrolló internamente? ¿Cuánto tiempo después de su lanzamiento, los externos tendrán que probar y proponer cambios en el diseño de la API? Mi principal preocupación sobre cómo se verán las API "enchufables" y "extensibles", ¿seremos capaces de "asumir el control" y tener un control completo del formato de cable de los tipos de referencia / valor? ¿Qué pasa con los tipos integrados, enumeraciones, bools, otros elementos intrínsecos, etc.? Por ejemplo, a modo de ejemplo, podrá configurar bool para aceptar otros valores JSON populares como "sí", "on", "1".

Otras preguntas:

• ¿Se puede usar esta implementación de forma independiente (en un paquete NuGet separado)?
• ¿La parte "enchufable" de la API está vinculada al marco web o se puede usar en otro lugar (por ejemplo, Xamarin / UWP)?
• ¿Admitirá .NET Standard 2.0 o .NET v4.5?
• De lo contrario, ¿podrán las API admitir .NET Standard 2.0 o .NET v4.5?

@mythz
Realmente no está desarrollado internamente (según mi conocimiento), la parte Reader / Writer se realiza en corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) y, específicamente, todavía no existe una API de alto nivel en corefxlab.

Personalmente, me gustaría que las partes de API extensibles / conectables sean .NET Standard (es decir, atributos, etc.). La biblioteca en corefxlab es .NET Standard 1.1 en este momento, pero imagino que esto cambiará dependiendo de los objetivos de rendimiento de la biblioteca, etc.

@mythz

Parece estar ansioso por tomar mis declaraciones y ponerlas en un contexto de "el vaso está medio vacío". Lo entiendo, eres escéptico. Sugiero que nos ahorremos un montón de pulsaciones de teclas y discutamos propuestas concretas de API en lugar de discutirlas en abstracto. Estoy bastante convencido de que nuestro plan proporcionará los puntos de extensión que necesita.

@terrajobst No estoy tratando de ser escéptico, tratando de saber cuáles son las capacidades propuestas de alto nivel que supongo que ya se han decidido (¿o todavía están por determinar?). Este anuncio es el primero que la mayoría de nosotros ha oído hablar de él, así que busqué algunas aclaraciones sobre lo conectable, extensible y reutilizable que debe ser. ¿ System.Text.JsonLab es el

Esta podría ser una buena característica para los creadores de bibliotecas, pero también debe considerar que los desarrolladores empresariales usan 50 bibliotecas con árboles de dependencia y tratan de encontrar compatibilidades entre ellas. ¿Habrá configuraciones de mapeo de estilo de redireccionamiento vinculante para tratar de gestionar las discrepancias?

Esta conversación parece nerviosa, ya sea porque las personas se han ofendido de alguna manera o porque están tratando de defender una acción que se tomó o no. Es dificil de leer. ¡Disculpas alrededor! Por favor, deje que el estado actual sea y siga adelante.

Parece que hay dos razones para este cambio. Primero está el deseo de mejorar el rendimiento utilizando nuevos tipos dentro de .Net Core.

Además, se reconoció que hace algún tiempo se cometió un error arquitectónico al incluir referencias duras a JSON.Net, una biblioteca que reside externamente a .Net. Para solucionar este problema, se debe realizar la introducción de una nueva implementación JSON incorporada junto con interfaces que permitan a terceros utilizar sus propias implementaciones.

¿Esto romperá las cosas? ¡Sí! Es por eso que el anuncio tiene una etiqueta de "cambios importantes". (Quizás esa etiqueta debería replicarse aquí). Y dado que se sabe que esto es un cambio rotundo, se inició una discusión para explorar el impacto. Además, para minimizar el impacto, se proporcionará una biblioteca adicional que permita a las personas continuar usando JSON.Net.

Como autor de una biblioteca, estoy realmente interesado en esto y preferiría que la conversación avanzara.

@Tornhoof en respuesta a sus ejemplos, si quisiera continuar usando JSON.Net, también necesitaría hacer referencia a la biblioteca de compatibilidad que mencioné anteriormente. Debería ser en su mayoría plug-and-play, pero puede haber cambios. Definitivamente no quiero que el marco (.Net Core) dicte que el serializador que elijo DEBE usar estos atributos para la serialización, especialmente cuando mi serializador usa un mecanismo diferente para conceptos similares.

La solución proporcionada por .Net debería ser más genérica que eso. La implementación de JSON elegida debe realizar la manipulación de serialización de modelos específicos.

@mythz De todo lo que sé y he visto de las personas involucradas en hacer esta propuesta, tendrá una gran oportunidad de revisar y comentar sobre la API propuesta y la implementación antes de que se publique como estable. Uno de los propósitos de hacer esta publicación en una etapa tan temprana fue encontrar personas como tú específicamente por esta razón.

@gregsdennis
No estoy seguro de a qué te refieres con más genérico.
Suponiendo que su serializador tiene el concepto de anular los nombres de propiedad json, cambiando su comportamiento nulo y / o implementaciones de respaldo / catch-all y asumiendo que las tres características son parte de la especificación compartida para serializadores JSON para .net core 3.0, luego el paquete de implementación asigna esos atributos a los detalles de su implementación interna.
Por ejemplo, si su biblioteca prefiere que use [DataMember] para especificar el nombre de las propiedades (como lo hace SpanJson), su paquete de integración debería mapearse así de fácil.
No estoy diciendo que los atributos sean la forma correcta, simplemente es una parte visible del ejemplo de código.

Obviamente, el mundo ideal sería que ninguna biblioteca de marco ASP.NET Core usaría anotaciones específicas para controlar el comportamiento de serialización, pero en cuanto a esa característica anterior, es bastante complicada o imposible, porque el RFC requiere que se sigan ciertas reglas de nomenclatura. .

De cualquier manera, creo que habrá muchas discusiones sobre estas características compartidas, cómo usarlas y describirlas en el futuro.

¿Tiene planes de utilizar instrucciones SIMD en el nuevo analizador JSON, como en RapidJSON?

Referencia: http://rapidjson.org/

La sugerencia propuesta se ve bien, pero por favor, intente suavizar los " cambios importantes ". Soy solo un usuario general de bibliotecas de terceros y recientemente tuve una de estas experiencias en las que la reflexión se excluyó repentinamente del proceso de compilación de versiones nativas de UWP .net (compilador ).

Por lo tanto, ninguna de mis aplicaciones para UWP se pudo compilar en modo de lanzamiento durante meses, ya que tuve que reescribir todo el código que usaba la reflexión en bibliotecas de terceros. Sé que muchos autores de bibliotecas tuvieron que dividir sus implementaciones nuevamente para excluir la reflexión en esas partes de UWP. La mayoría de los autores de bibliotecas no asistieron a la fiesta y me vi obligado a abandonar el barco. Aunque MS pasó a primer plano y se comprometió a implementar una alternativa en el estándar 2.1 de .net. sabemos que la realidad sobre el terreno es que el estándar 2.1 de .net tardará meses en entregarse desde el cambio radical inicial.

El punto es simplemente, este fue un proceso enormemente disruptivo para mí que tuvo consecuencias masivas para los usuarios finales y fue todo menos "suave" y sin fricciones.

Este es definitivamente el paso correcto a seguir.
Me pregunto por un momento ver esta referencia de Json.Net.

@Tornhoof Creo que debe haber una separación definida: las interfaces que cada proveedor necesitaría implementar para poder usarse con .Net Core 3.0 y la implementación predeterminada que está incorporada.

Las interfaces deben ser de uso tan generalizado como sea posible. Quizás tan simplista como definir solo los métodos Serialize() y Deserialize() .

Otros detalles deben dejarse a la implementación. Si la implementación predeterminada usó un atributo para definir un mecanismo de codificación de propiedad personalizada, estoy de acuerdo con eso. Creo que es un detalle específico de la implementación que no debería ser parte de la interfaz.

Dicho esto, tener la capacidad de personalizar las propiedades de clave podría ser un requisito, aunque no estoy seguro de cómo podría codificarse.

@gregsdennis Sí, tienes razón, estaba mirando principalmente el IInput / OutputFormatter, que ya existe actualmente en ASP.NET Core y específicamente los problemas relacionados con reemplazarlos con versiones que no son JSON.NET.
De todos modos, como muestran sus comentarios y @mythz , supongo que la definición del alcance se volverá interesante y probablemente no tan simple (recuerdo los problemas con las especificaciones de la interfaz DI). Por lo tanto, es mejor involucrar muchos puntos de vista diferentes al principio del proceso.

@Tornhoof estuvo de acuerdo. Las interfaces del formateador actuales están claramente basadas en JSON.Net, pero no tanto en el serializador en sí, sino en el objeto de opciones. Parece que también necesitaríamos una forma genérica de comunicar opciones (un objeto de opciones común).

¿Implica esto que el objeto de opciones dicta un conjunto mínimo de características para una implementación? No creo que lo haga. Recientemente implementé un formateador para mi serializador que ignora por completo el objeto de opciones, pero era para mi uso privado. Si quisiera hacer uno para uso público, trataría de interpretar tantas de esas opciones como sea posible para respaldarlas.

No es así como estamos haciendo las cosas ahora. Las opciones son específicas del serializador y no hay una interfaz común para ellas. Los formateadores en MVC ya están factorizados correctamente y no están acoplados a nada. JsonResult tendrá cambios importantes porque toma JsonSerializationOptions directamente (el tipo JSON.NET).

Estaba a punto de decir lo mismo. No planeamos construir una abstracción para un lector / escritor / serializador JSON. No es necesario; Los frameworks se ocupan de primitivas IO (como Stream , TextReader ) o se conectan al procesamiento de framework de nivel superior (como los formateadores ASP.NET Core).

Hablando de puntos débiles: Personalmente (y probablemente estoy en una minoría muy pequeña) me preocupa la naturaleza laxa de muchos analizadores JSON. Existe un estándar (tm), pero la mayoría de los analizadores optan por ser indulgentes y aceptar documentos no conformes. Lo malo de eso a largo plazo es que los desarrolladores no implementan hacia un estándar que implementan hacia una biblioteca. Si la biblioteca permite un documento no conforme, los desarrolladores están contentos siempre que todos los bits utilicen la misma biblioteca. El dolor surge al intentar comunicarse entre dominios que utilizan diferentes bibliotecas. De repente, surge un problema porque diferentes bibliotecas admiten diferentes sabores de JSON.

¿Deberíamos eliminar los puntos débiles haciendo que la biblioteca JSON sea lo más indulgente posible (pero tal vez termine con complejidad y ambigüedad) o atacando la causa raíz? Bibliotecas JSON no confirmadas.

Como es MS influyente, quizás hay mucho que pedir para que MS defienda con éxito los analizadores JSON compatibles con el fin de mejorar la interoperabilidad a largo plazo, pero desearía que fuera diferente. ¿Quizás ser indulgente con la lectura pero estricto con la escritura?

(Cosas que no están en el estándar; comentarios, comas finales, cadenas de comillas simples, sin cadenas de comillas, etc.)

En mi humilde opinión, dado que JSON proviene del mundo de los navegadores web, parece que para la interoperabilidad deberíamos elegir el doble como la representación subyacente de los números en JSON, aunque el estándar JSON no dice nada sobre el representante.

Hablando sobre la API, asumo implícitamente que la API más utilizada será una API similar a DOM, pero también me resultaría muy útil si hubiera una API de nivel inferior que me permitiera consumir el flujo de tokens o recibir una señal en una interfaz de visitante para esos documentos grandes de los que solo quiero extraer una pequeña parte de los datos.

@mrange : por mucho que me guste hacer las cosas lo más estrictas posible ... hacerlo depende de la capacidad de realizar cambios en el código no conforme.

Si está interactuando con un servicio heredado bajo el control de otra empresa, la capacidad de cambiar el código infractor es casi nula. Incluso el estricto en escritura, aunque es más factible, no está exento de problemas aquí: ¿qué pasa si el código infractor espera recibir un objeto no conforme?

@terrajobst ¡ gracias! Func<Stream, CancellationToken, Task<T>> y Func<T, CancellationToken, Stream, Task> es todo lo que se necesita aquí. Quizás con algunas sobrecargas para TextReader / Writer, Span y string.

Sin embargo, la desventaja es cuando desea serializar / deserializar el tipo de otra biblioteca, y ese tipo está decorado con atributos de un serializador json que no está utilizando.

@thefringeninja si ya está utilizando la biblioteca de terceros para los objetos, entonces ya tiene una referencia al otro serializador. Allí nada ha cambiado.

No soy de los que fomentan el miedo, pero creo que

@terrajobst Con respecto al ecosistema, aunque es imposible dar cuenta de todas las bibliotecas, no creo que una búsqueda rápida de "json" en NuGet le diga mucho a nadie. Quizás el nombre ServiceStack.Text no sea la forma más directa de decir "¡Oye! ¡Soy un paquete que puede (des) serializar JSON!", Pero ha habido puntos de referencia a lo largo de los años que lo comparan. Tal vez se trate de una prueba interna de los valores predeterminados de MS y de no conocer la amplitud y popularidad de las alternativas o de usarlas internamente con la suficiente frecuencia para familiarizarse con ellas.

Estoy de acuerdo en que debería haber algún valor predeterminado para proporcionar una experiencia que _ simplemente funciona_ lista para usar. Si otros autores de bibliotecas en el ecosistema publican un paquete de integración, sería genial si pudieran obtener un complemento en los documentos, notas de la versión, etc. para enfatizar que hay alternativas más allá de los valores predeterminados. Hacer que sea difícil de descubrir sería problemático para el ecosistema.

Mi esperanza es que si el objetivo de eliminar la dependencia es sincero, las API deberían representar mejor las necesidades de la comunidad y no estar modeladas directamente a partir de Json.NET. La conclusión es que requerirá el trabajo de todos los autores de la biblioteca, no solo de ServiceStack, pero las API no deberían parecerse directamente a la API de Json.NET; de lo contrario, volverá a lo que parece una dependencia pero sin la dll.

las API no deben parecerse directamente a la API de Json.NET

... o la implementación de cualquier otro proveedor específico.

Parte de la discusión que tuvo lugar antes del anuncio incluyó la idea de que el equipo de .Net se basaría en varias bibliotecas para tener una idea de cómo se han resuelto varios problemas, y luego usar lo que ellos consideren sería el mejor ajuste de esos. ideas combinadas con las propias. En muchos sentidos, no es muy diferente a cómo se desarrollaría cualquier otra biblioteca JSON nueva; simplemente sucede que este se incluirá dentro del marco.

Estamos comprometidos con tener una biblioteca JSON de alto rendimiento que no tenemos que construir nosotros mismos. :)

Antes de discutir cualquier cosa, considere aprovechar los resultados de la investigación de Microsoft en esa área (más específicamente, el análisis sin ramificaciones ni FSM) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -análisis-de-datos /

Vamos en esa dirección para el análisis JSON de alto rendimiento --- además de Span<T> por supuesto ---
cc @terrajobst @karelz

:( toda esta discusión sobre JSON me hace sentir que mi pregunta sobre las plantillas ha salido mal.

Ojalá tuviera más tiempo para esta discusión porque ha sido un infierno, pero veo por qué se ha convertido en lo que es. 4.6.1 tiene que ser coherente con las actualizaciones y actualizaciones y los cambios importantes serán para el resto.

He visto muchos paquetes retirados para core y 461 y espero que este tipo o cambio lo solucione.

Me preocupa que el problema de la cascada nos persiga, demuéstranos que estamos equivocados.

// desarrolladores de dot net en todas partes

@ c0shea

[…] Sería genial si pudieran obtener un complemento en los documentos, notas de la versión, etc. para enfatizar que hay alternativas más allá de los valores predeterminados.

Estoy seguro de que ese será el caso. Los documentos ya enumeran implementaciones alternativas para múltiples temas, como contenedores DI , proveedores de registro , integración Swagger o proveedores de bases de datos EF Core .

@ phillip-haydon
El sistema de plantillas ya admite plantillas personalizables, y las plantillas existentes ya tienen varias opciones. Solo echa un vistazo, por ejemplo, a dotnet new mvc --help para ver lo que es posible actualmente. Estoy seguro de que podría ampliarlo fácilmente con, por ejemplo, integraciones de serializador JSON alternativas, y las solicitudes de funciones o solicitudes de extracción para eso probablemente se aceptarán en aspnet / Templates .

@mrange : por mucho que me guste hacer las cosas lo más estrictas posible ... hacerlo depende de la capacidad de realizar cambios en el código no conforme.

Si está interactuando con un servicio heredado bajo el control de otra empresa, la capacidad de cambiar el código infractor es casi nula. Incluso el estricto en escritura, aunque es más factible, no está exento de problemas aquí: ¿qué pasa si el código infractor espera recibir un objeto no conforme?

Tal vez tenga un modo estricto de forma predeterminada y pueda cambiarlo explícitamente a un modo más indulgente

@poke Supongo que realmente necesitas probar vue cli y luego volver a intentar dotnew new. El nuevo dotnet actual ... es ... es ...

¿Puedo solicitar que recuerde que el análisis de JSON de varios navegadores no admite valores int64 correctamente y nos da la capacidad de serializar / deserializar longitudes como cadenas? Es una de esas cosas que no notas hasta que te muerde con fuerza. Una variación de esto es poder decidir si los números se deserializan en ints o longs de forma predeterminada.

¿Puedo solicitar que recuerde que el análisis de JSON de varios navegadores no admite valores int64 correctamente y nos da la capacidad de serializar / deserializar longitudes como cadenas? Es una de esas cosas que no notas hasta que te muerde con fuerza. Una variación de esto es poder decidir si los números se deserializan en ints o longs de forma predeterminada.

.... Ah, EcmaScript, gracias por hacer que todo se duplique. Estoy seguro de que eso no ha causado problemas en alguna otra parte del código ...

Como purista, no me gustan este tipo de cosas.
Como realista, creo que tendré que estar de acuerdo con esto.

¿Alguna parte de la nueva implementación de JSON estará en .Net Standard 2.1 ?

He estado siguiendo esto un poco y no estoy seguro si me lo he perdido. ¿Existe una interfaz o superficie API propuesta que pueda revisar? Me interesa ver la superficie de la API para esta propuesta.

¿Existe una interfaz o superficie API propuesta que pueda revisar?

Aún queda mucho por hacer, pero https://github.com/dotnet/corefx/pull/33216 es un comienzo. Aquí están las notas de revisión de

ACTUALIZACIÓN: Hoja de ruta también disponible aquí .

Entonces, ¿qué tan completa se comparará la API de aspnet 3.0 con la API de json.net? Además, ¿json.net, a todos los efectos, se eliminará gradualmente mediante el desarrollo de nuevas aplicaciones con api nativas?

simplemente mejorar el rendimiento o los medios reemplazar todas las funciones de json.net?

Esta es una noticia asombrosa.

Recomiendo encarecidamente intentar colaborar con @neuecc, su trabajo con MessagePack , Utf8Json , ZeroFormatter , etc. ha sido fenomenal.

@linkanyway, el resultado sería reemplazar un subconjunto de json.net, mientras proporciona nuevas apis sin asignación.

Sospecho que la mayoría de los usuarios de aspnet no dependerían mucho de la implementación de json.net y podrían migrar casi sin problemas.

¿Existe una interfaz o superficie API propuesta que pueda revisar?

Aún queda mucho por hacer, pero dotnet / corefx # 33216 es un comienzo. Aquí están las notas de revisión de

ACTUALIZACIÓN: Hoja de ruta también disponible aquí .

@khellang ¿Vamos a recibir alguna ayuda de lang para que podamos escribir json en c # de verdad?

Otro buen movimiento en dirección OSS. Motivará a los desarrolladores de otras plataformas comerciales a desarrollar algo mejor de lo que MS ya hace de forma gratuita, o se convertirán en OSS por completo si realmente se preocupan por la comunidad.

¿Vamos a obtener alguna ayuda de lang para que podamos escribir json en c # de verdad?

@dotnetchris No estoy seguro de lo que quieres decir con "ayuda lang". ¿Literales JSON? Dudo que eso suceda. ¿Ha mirado la próxima función de "lenguaje integrado"? ¿Específicamente para JSON ?

@khellang eso es ciertamente un paso en la dirección correcta, pero me refiero a un apoyo total. Usando los mismos objetos de muestra de su enlace, más parecido a:

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

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

Con suficiente vudú, como la generación implícita de objetos tupla / valuetuple / record para que todo funcione a nivel de idioma detrás de escena.

Por el contrario, el compilador podría invocar los servicios json, crear una clase y luego trabajar con una instancia de la clase como si escribiera:

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

Editar: LOL @ downvoters.

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

@dotnetchris Si está interesado, vote en https://github.com/dotnet/roslyn/pull/24110. Ha sido cerrado por el equipo de IDE por falta de interés. Pero si hay suficientes votos, tal vez eso pueda cambiar.

¿Las API JSON "incorporadas" y "proporcionadas por la plataforma" significan que no será un paquete nuget separado (estándar de red)? Si no es así, ¿por qué no?

Supongo que el nuevo marco compartido ASP.NET Core no puede depender de paquetes nuget, ¿o sí?

¿No existe ya un espacio de nombres

Eliminarlo rompería la compatibilidad con versiones anteriores. Dejarlo e iniciar una nueva API puede causar cierta confusión. Expandirlo / mejorarlo sin eliminar ninguna API puede ser un poco restrictivo al agregar nuevas API.

Sería genial tener interfaces para JsonReader / JsonWriter, porque hay otras fuentes y destinos además de las transmisiones. Por ejemplo, también uso JSON.NET para MongoDB. Es más rápido y no tengo que mantener múltiples serializadores en mis aplicaciones.

Sé que podría perjudicar un poco el rendimiento, pero es muy útil.

@SebastianStehle : JsonReader / JsonWriter son abstracciones de alto nivel, ver el comentario de terrajobst

El plan para 3.0 es el siguiente:

1. API JSON de alto rendimiento integradas. Lector / escritor de bajo nivel, un lector / escritor basado en Stream y un serializador.
2. ASP.NET Core se puede conectar al componente JSON.

Hay una pregunta abierta sobre qué utilizarán las plantillas para ASP.NET en 3.0. Dependiendo de la fidelidad que podamos proporcionar con 3.0, podríamos hacer que extraigan el paquete de integración Json.NET. Sin embargo, el objetivo es ofrecer suficiente fidelidad y paridad para depender solo de los integrados de forma predeterminada.

La API de alto nivel y fácil de usar se envolvería alrededor de las transmisiones para deserializar fácilmente desde y hacia las transmisiones (esto suele ser lo más común, al serializar. Si desea el mejor rendimiento en escenarios donde no puede usar transmisiones, debe usar la baja API de nivel que operan en Span<T> o Memory<T> , especialmente cuando ya tiene los datos a mano / en la memoria, desea usarlos y no tener la sobrecarga de async.

@TsengSR

https://github.com/neuecc/Utf8Json no proporciona la funcionalidad para escribir lectores / escritores personalizados debido a razones de rendimiento (llamadas virtuales y asignaciones, supongo) y pensé que les gustaría seguir el mismo camino. Pero hasta ahora no he visto ningún código de serialización todavía.

Estoy de acuerdo con @ JonasZ95 y @gregsdennis , espero que la implementación no sea una simple abstracción de los mismos detalles de implementación de JSON.Net, sino que se centrará en cómo debería verse.

También creo que debería abordarse como 2 funciones separadas ...

1. serialización / deserialización
2. json de dicha serialización y deserialización.

Con suerte, el marco ASP.NET Core utilizará una abstracción de serialización genérica en lugar de una abstracción específica de JSON.

En cuanto a la extensibilidad, espero que el marco utilice la técnica DI de codificación de abstracciones (interfaces, no clases abstractas) y simplemente proporcione un valor predeterminado local. Desde la perspectiva de los autores de la biblioteca JSON, esto proporcionaría la mayor extensibilidad porque todo lo que tendría que hacer es proporcionar una clase de adaptador ASP.NET Core que use la implementación de la biblioteca de las interfaces y luego configurar ASP.NET Core para usar el adaptador de la biblioteca.

La implementación para una biblioteca de terceros podría verse así:
`` C #
// referencia a bibliotecas de terceros
utilizando Newtonsoft.Json;

// ejemplo muy ingenuo por brevedad solo para
// Haz el punto
NewtonsoftAdapter de clase pública: ISerializer
{
private JsonSerializerSettings _settings;
_formato de formato privado;

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);
}

}

...

// adaptador de configuración con opciones de personalización de terceros
var settings = new JsonSerializerSettings
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = new NewtonsoftAdapter (configuración, Formatting.Indented);

// configurar el núcleo de asp.net
// donde el adaptador implementa ISerializer (o el nombre que se le ocurra)
// los autores de la biblioteca podrían incluso proporcionar su propio método de extensión UseXYZ ().
app.UseSerializer (adaptador);
''

Ha habido muchos avances en el análisis de texto basado en SIMD, incluso para texto estructurado, como JSON . ¿Existe alguna posibilidad de que el trabajo en .NET Core se acerque a este nivel de rendimiento? ¿Hay alguna forma de utilizar estas técnicas?

¡Incluso Microsoft Research tiene algunas nuevas soluciones de alto rendimiento!

@AnthonyMastrean Gracias por mencionar este tema. También estoy interesado en cualquier punto de referencia para tener una idea de cómo se compara este impl Json actual con simdjson.

Por cierto, los autores de simdjson dijeron que todavía están trabajando en la publicación completa de este proyecto (creo que más doc). Por ahora, puede leer alguna discusión interesante sobre este proyecto en HN .

¿Hay alguna forma de utilizar estas técnicas?

.NET Core 3.0 simplemente incluye un montón de elementos intrínsecos dependientes de la

Por lo que vale, creo que en un ámbito web, la red es un cuello de botella principal, y aunque es genial que pueda analizar gigabytes en segundos, no creo que sea muy útil para un proyecto web.

No me malinterpretes, las optimizaciones de rendimiento como estas son geniales y probablemente beneficiarían incluso a documentos JSON muy pequeños. Pero por ahora, creo que el enfoque de la nueva biblioteca es evitar la asignación de memoria y mover todo muy de cerca a la capa de red. Solo eso ya debería mejorar mucho el rendimiento sobre JSON.NET. Pero cuando se realiza el trabajo inicial, buscar optimizaciones adicionales podría ser otra historia.

Donde trabajo, analizamos tera bytes de JSON todos los días. También conozco otros que usan .NET y F # para procesar muchos documentos JSON. JSON se ha convertido en algo más que servidor => mecanismo de transporte del navegador. Se usa mucho en escenarios de backend puros.

DE C; Sería mejor para el backend cambiar a un formato binario como AVRO / Protobuf, pero a menudo eso es difícil y JSON tiene algunos beneficios (lo admito a regañadientes). Tener un analizador JSON realmente rápido podría literalmente ahorrar $ 10,000 dólares al mes para empresas similares a la nuestra.

@poke Este proyecto pertenece a .NET Core (no a ASP.NET ...), por lo que es relevante para todas las cargas de trabajo, no solo para la web.

Puedo estar de acuerdo con la idea de que es demasiado tarde para trabajar en esta técnica de optimización específica para .NET Core 3.0, pero espero que se realice alguna investigación ahora para garantizar que la optimización sea posible en el futuro (es decir, sin cambios importantes ).

¿Puede ser mejor hacer algo como un ensamblaje de mapeo unificado ('System.Text.Json.Mapping') donde definir atributos y otras cosas para mapear JSON a clases de C #? Después de implementar esto, todos los analizadores / escritores JSON existentes se pueden adoptar para usar el mapeo unificado. Permitirá que todas las aplicaciones .NET Standard migren entre diferentes bibliotecas JSON sin ningún problema.

@AlexeiScherbakov Las nuevas abstracciones en realidad no ayudan mucho. Simplemente se limitará nuevamente eligiendo una abstracción común y siempre habrá nuevas bibliotecas que no pueden usar la abstracción y requieren más. Siempre ha sido así, por ejemplo, con el registro .

No creo que la creación de una nueva abstracción basada en esta nueva implementación nos brinde ningún beneficio, especialmente cuando la biblioteca está diseñada para ser mucho menos rica en funciones de todos modos.

Y en realidad ya existe una abstracción estándar de red en forma de DataContract / DataMember que espero que esta biblioteca termine respetando (incluso si esa abstracción es algo limitada).

Aparte de un atributo de ignorar, no podemos tener mil millones de nuevos atributos y escenarios para atender. Preferiría mapeo 1: 1 de JSON a clases, si desea hacer algo fuera de la norma o respaldar el legado, use json.net.

Personalmente, no me preocupan mucho las clases JSON <=> C #. Creo que es importante tener el concepto de analizar / escribir JSON separado del modelo de objeto C # creado del modelo JSON.
De esa manera, yo (que no me importan mucho las clases JSON <=> C #) puedo tener un analizador realmente eficiente sin tropezar con algún modelo de objeto tipo.

@mrange para eso están el lector y el escritor

¿Eso significa que puedo esperar una API Reader / Writer en la API JSON proporcionada por la plataforma? ¿Es el patrón Lector / Escritor el más eficiente?

Hay 3 tipos en System.Text.Json partir de ahora :

• Utf8JsonReader : una forma rápida, sin caché y de solo avance para leer texto JSON codificado en UTF-8.
• Utf8JsonWriter - ^ igual que Utf8JsonReader , pero por escrito.
• JsonDocument : un modelo de documento de acceso aleatorio de solo lectura para cargas útiles JSON.

Todos los tipos anteriores deberían ser (más o menos) libres de asignación 👍

Publicamos el documento de simdjson: https://arxiv.org/abs/1902.08318

También hay trabajo en curso en un puerto C # de simdjson: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

¿Puede ser mejor hacer algo como un ensamblaje de mapeo unificado ('System.Text.Json.Mapping') donde definir atributos y otras cosas para mapear JSON a clases de C #? Después de implementar esto, todos los analizadores / escritores JSON existentes se pueden adoptar para usar el mapeo unificado. Permitirá que todas las aplicaciones .NET Standard migren entre diferentes bibliotecas JSON sin ningún problema.

Realmente espero que la nueva abstracción no se base en atributos. Intento usar objetos POCO limpios en las bibliotecas subyacentes y uso DI para evitar que tengan que conocer la implementación. Definitivamente no quiero decorar mis clases subyacentes con atributos requeridos para la implementación. Esto podría terminar haciendo que se creen clases adicionales en las capas de la interfaz de usuario que esencialmente solo mapean un objeto de dominio existente a json.

Probablemente el mapeo 1-1 de json a clases c # sería un mejor enfoque, al menos en algunos casos podría evitar crear nuevas clases incluso si las clases de tipo viewmodel seguirán siendo necesarias en otros casos.

Sin embargo, sería bueno si hubiera alguna forma de ignorar las propiedades que no son necesarias y, al menos, controlar algunos de los aspectos de serialización (como la carcasa camel vs pascal).

@mrange para eso están el lector y el escritor

@davidfowl ¿

El soporte de serialización está aterrizando en estos momentos . El problema relacionado dice:

• Debido a las limitaciones de tiempo y para recopilar comentarios, el conjunto de características está destinado a un producto mínimo viable para 3.0.
• Se apuntan escenarios de objetos POCO simples. Suelen utilizarse para escenarios DTO.
• La API diseñada para ser extensible para nuevas funciones en versiones posteriores y por la comunidad.
• Atributos en tiempo de diseño para definir las diversas opciones, pero aún admiten modificaciones en tiempo de ejecución.
• Alto rendimiento con IL Emit con respaldo a la reflexión estándar para compatibilidad.

También detalla cómo planean admitir la conversión de enumeración, el manejo de nulos, camel- vs PascalCasing, etc.

Si tiene comentarios sobre algo de esto, debe dejar sus comentarios en ese problema o en la solicitud de extracción.

@lemire Wow, eso es realmente genial. simdjson es realmente súper rápido.

¿Alguna posibilidad de que pueda implementar el punto de referencia de serialización JSON de TechEmpower ? (Sé que será mucho más trabajo)

Encontré estas implementaciones: En el repositorio de TechEmpower y en el repositorio de ASP.NET .

@KPixel Esto es serialización, ¿verdad? Mientras tanto, simdjson es un analizador ... A menos que esté confundido acerca de los términos, ¿estas cosas van en direcciones opuestas?

Mi error. Supuse que había una parte de deserialización (que usaría el analizador).

¿El System.Text.Json será un paquete nuget estándar de .net? o ¿Es algo que solo está disponible para .net core 3.0?

@ John0King echa un vistazo aquí: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Creo que la usabilidad también debería ser un foco del nuevo paquete JSON. Una característica que creo que debería tener es la compatibilidad con la validación del esquema JSON. Newtonsoft cobra por eso. Esto es algo lo suficientemente fundamental como para proporcionarlo en la plataforma de forma gratuita, como fue el caso de la validación de esquemas XML.

@ jemiller0 Mi impresión es que la validación XML ha sido un tanto mixta y el esquema JSON ha tenido una adopción

@lemire Sí, es un gran problema si está desarrollando software de código abierto y desea que su software esté disponible para todos. El análisis de XML no es una mezcla. Funciona. Lo mismo ocurre con la validación del esquema JSON. No tener una forma gratuita incorporada de hacer esto hace que la plataforma .NET no sea competitiva.

Nunca he visto el esquema json utilizado en el mundo real. Así, no debe ser parte de la implementación discutido aquí. Y ninguno de los mil millones de otras características y peculiaridades de json.net debería implementarse aquí tampoco. Esto no debería ser más que una implementación rápida y súper liviana. Si no está satisfecho con la necesidad de una licencia de json.net para admitir la validación de json. Cree su propia implementación de código abierto y hágala disponible gratuitamente.

@ jemiller0

Tengo mucha curiosidad: ¿otros lenguajes de programación ofrecen soporte para esquemas JSON en su biblioteca estándar?

El objetivo de esta biblioteca es ser una biblioteca de alto rendimiento y bajo nivel para trabajar con JSON. Cualquier cosa que no sea eso, que incluye la mayoría de las características más avanzadas de JSON.NET y también esquemas JSON, no será parte de esto.

Si desea la validación del esquema JSON, puede implementar un validador en la parte superior de esta biblioteca, que debe ser lo suficientemente bajo como para permitirle hacer eso.

No creo que tener la validación del esquema JSON en una biblioteca estándar tenga nada que ver con que una plataforma sea competitiva o no.

El objetivo de esta biblioteca es ser una biblioteca de alto rendimiento y bajo nivel para trabajar con JSON. Cualquier cosa que no sea eso, que incluye la mayoría de las funciones más avanzadas de JSON.NET, no será parte de esto.

Excepto que también incluirá funciones de nivel superior, diseñadas para ser un reemplazo directo de Newtonsoft.Json 😊

@poke Tienes derecho a tener cualquier opinión que quieras tener, al igual que yo. XML se utiliza en todas partes. Por lo tanto, con razón, Microsoft incluyó soporte de validación con .NET Framework. Ahora, JSON está de moda y se usa EN TODAS PARTES, en archivos de configuración, API web, etc., etc. Tiene sentido tener el mismo nivel de soporte para JSON que históricamente fue compatible con XML. Personalmente, me parece un poco ridículo que Microsoft esté haciendo uso de software de terceros para empezar. Esa debería ser una característica central de la plataforma.

@lemire Pronto

Utilizo JSON Schemas en el trabajo y prefiero tener un analizador JSON realmente bueno que un analizador JSON medio bueno + validador de esquema JSON. También AFAIK JSON Schema es un _draft_ 7 en este momento. Entonces, tener el esquema JSON como una biblioteca externa que puede evolucionar rápidamente junto con el esquema tiene sentido para mí. Sin embargo, sería bueno tener JSON Schema en la hoja de ruta.

@ jemiller0

Tiene sentido tener el mismo nivel de soporte para JSON que históricamente fue compatible con XML.

.Net también incluye soporte para XSLT y XPath. Si desea "el mismo nivel de soporte", ¿no significa eso que también necesitaría alguna versión de esos para JSON?

Lo que intento decir es: el ecosistema JSON es diferente del ecosistema XML. Ambos tienen diferentes patrones de uso y las tecnologías relacionadas tienen diferentes números de uso y niveles de estandarización. Además, se agregó XML a .Net antes de que existieran NuGet, git o GitHub. Hoy en día, es mucho más fácil y aceptable confiar en una biblioteca de terceros.

Entonces, no, no creo que tenga sentido decir ciegamente "XML tenía esto, entonces JSON tiene que tenerlo también".

Además, la validación es simplemente ortogonal al análisis. Estoy absolutamente bien con que se agregue soporte de validación en algún momento (posiblemente en otro paquete por completo). Pero no es en absoluto necesario para un soporte de análisis adecuado.

Necesitamos una forma de validación estricta de datos en solicitudes REST de API.
Porque guardamos el json que viene a través de la API sin errores y luego no podemos analizarlo en JS debido a las comas finales, etc.

¿Y por qué no puede validar esa solicitud ahora?

@ phillip-haydon @ freerider7777 Creo que cualquier analizador JSON decente debería cumplir con la especificación JSON y arrojar errores (y / o advertencias) cuando el documento no está bien formado (por ejemplo, cuando tiene comas al final). Eso es bastante básico pero también distinto de la validación, que es la comparación de los datos JSON con un esquema (al menos, así es como utilizo los términos).

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

Microsoft, una de las empresas de desarrollo de software más grandes que existen, no tiene a nadie con quien trabajar en la validación. Un analizador rápido es más importante. Le permitirá analizar el JSON inválido a la velocidad de la luz. :-) A nadie se le ha ocurrido que la validación rápida podría ser útil. Esto al igual que ASP.NET Core, una rápida actualización simplificada a Web Forms.

¿Y por qué no puede validar esa solicitud ahora?
@ phillip-haydon En el código del controlador con tal json:
ModelState.IsValid == verdadero

🤦‍♂️

Puede hacer la validación basada en su esquema json ya con 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>

Estoy de acuerdo con @lemire , hay una diferencia en validar la estructura de JSON y validar el JSON contra un esquema. No tengo ninguna duda de que Microsoft ha dedicado tiempo y esfuerzo para implementar correctamente el primero ... el segundo es un caso de esquina y no creo que encaje en el diseño general de esta biblioteca JSON. Estoy bastante seguro de que han dejado en claro que esta biblioteca JSON está diseñada ÚNICAMENTE para proporcionar un análisis rápido y eficiente según sea necesario para que funcione el núcleo de asp.net. No fue diseñado para incluir los _extras_ que venían con el analizador de newtonsoft. (consulte el comentario de @poke anteriormente en el hilo).

No creo que el hecho de que intencionalmente no hayan diseñado esto para que venga con todas las comodidades lo convierte en un producto inferior.

¿Sucedió esto para enviar con la vista previa 4?

¿Hay planes para hacer que System.Text.Json.Serialization.Policies.JsonValueConverterclass public para permitir la sustitución de clases de convertidor de Json.net?

¿Se enviará System.Text.Json con soporte completo de .Net a través de nuget? Seguramente sería bueno garantizar la interoperabilidad completa, así como aprovechar los beneficios del marco completo.

System.Text.Json se modificó recientemente para producir netstandard2.0 binarios para enviar OOB; https://github.com/dotnet/corefx/pull/37129 :

Si es posible, debe apuntar a .NET Core 3.0 y obtener las API System.Text.Json incluidas. Sin embargo, si necesita admitir netstandard2.0 (por ejemplo, si es un desarrollador de bibliotecas), puede usar nuestro paquete NuGet, que es compatible con netstandard2.0.

se beneficia del marco completo

¿Qué son estos de nuevo? 🤔

@khellang

Mi preferencia sería un nuget con múltiples sabores, incluido el marco completo (4.5 o el mínimo aceptable), estándar y básico. Es preferible usar conjuntos en caja.

El problema vinculado anteriormente se refiere a este paquete, pero no es compatible:

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

¿Existe un paquete compatible actualmente?

Mi preferencia sería un nuget con múltiples sabores, incluido el marco completo (4.5 o el mínimo aceptable), estándar y básico.

¿Por qué preferirías eso? Si no hay necesidad de un objetivo múltiple, es decir, todas las API utilizadas son parte del estándar, es mucho mejor tener un solo objetivo 😊

¿Existe un paquete compatible actualmente?

No creo que se haya enviado todavía. El PR se fusionó hace días. Ese paquete solía ser un proyecto comunitario que ahora se ha transferido a MS.

@khellang , depende de los detalles: estaba haciendo una declaración general.

Si la versión net estándar tuviera que omitir algo de la versión net core que sería posible con la versión net full, preferiría que los tres sabores estuvieran disponibles. El mismo razonamiento general, sospecho, que la declaración original del problema vinculado anterior sobre la preferencia de los usuarios para apuntar a la versión en caja.

Al agregar una referencia al paquete nuget, se seleccionaría automáticamente el sabor más compatible apropiado. Entonces, no es gran cosa. Si la biblioteca consumidora es estándar neto, entonces se seleccionaría el sabor estándar neto.

Mi preferencia general por los sabores en caja es que cuando goto definition , obtengo fuentes descompiladas. Si goto definition en bibliotecas estándar de red, normalmente solo veo fuentes de código auxiliar que arrojan excepciones NotImplemented .

se beneficia del marco completo

¿Qué son estos de nuevo? 🤔

Muchas aplicaciones usan .NET Framework no porque quieran absolutamente mantenerse fuera de .NET Core, sino porque .NET Core no es una opción. Yo uso .NET Core cuando es una opción; cuando tengo que apuntar a versiones de Windows inferiores a Windows Server 2012 (la versión mínima de .NET Core 3.0), tengo que usar .NET Framework. Por mucho que esté seguro de que fue una decisión muy dolorosa abandonar el soporte para Windows Server 2008 R2 y versiones anteriores, es una decisión muy dolorosa para todas las empresas con clientes que pagan con servidores que no quieren actualizar /, a menudo, básicamente, volver a crear desde cero. solo para que podamos usar una herramienta un poco más nueva.

Nadie estaría más feliz que yo si pudiera dejar de usar .NET Framework mañana, pero incluso con todas las oportunidades de WPF y Windows Forms en .NET Core 3.0 y más allá, Microsoft lo está haciendo prácticamente imposible con sus políticas de soporte. Intenté discutir esto con cualquiera que quisiera escuchar en Microsoft, pero lamentablemente, todavía no he recibido ni un correo electrónico reconociendo que el mensaje fue entregado.

@JesperTreetop sin mencionar la falta de compatibilidad con LTS para las versiones de .NET Core que vale la pena usar para una empresa;) Espero que obtengamos compatibilidad con LTS en 3.x; como arquitecto .NET de mi organización, estaré presionando para Adopción de .NET Core si obtenemos una versión 3.x con soporte LTS.

@marksmeltzer La publicación de blog Presentando .NET 5 de ayer muestra que .Net Core 3.1 será LTS y está previsto que se publique en noviembre de 2019.

¿Este nuevo serializador JSON admitirá los tipos F #?

@rliman bueno, actualmente no es compatible con Guid o Enum, por lo que tiene un largo camino por recorrer. Estoy de acuerdo en que en mi humilde opinión debería requerirse soporte completo para los tipos de opciones de F # que son similares a los que aceptan valores NULL de C #

Personalmente, creo que esta es una solución apresurada para una mala decisión de diseño arquitectónico. Esto debería haberse hecho hace mucho tiempo ... Ahora va a causar mucho dolor en todas partes ... Desde desarrolladores de bibliotecas hasta desarrolladores empresariales.

No hay una manera fácil de "suavizar" esta nueva "característica".

Esta es la EM que intenta resolver un problema que causaron en primer lugar. Y ahora todo el mundo tiene que pagar el precio.

Con NET Core parece desde el principio que el vagón es un poco "rápido" ... Este enfoque "ágil" puro podría necesitar reducir la velocidad un poco y dejar que todos recuperen el aliento.

Parece que con ASP.NET Core estas "características" (cambios importantes) se han convertido en la nueva normalidad.

En mi opinión, ASP.NET Core necesita desesperadamente una reelaboración de su proceso de diseño arquitectónico. Porque una y otra vez siga haciendo estas características de "lo arreglaremos más tarde".

He estado desarrollando con ASP.NET Core desde que estaba en las primeras versiones beta ... Y es una gran mejora en .NET.

Pero el equipo de MS debería detenerse por un momento y pensar cómo pueden abordar el problema real aquí: decisiones de diseño arquitectónico apresuradas e inconsistentes.

Vuelve atrás y lee otros hilos ... Parece que es un tema recurrente.

Por lo tanto, puede que sea hora de sentarse y volver a pensar cuál es el mejor enfoque para hacer un producto más estable.

Es posible que .NET clásico no sea tan poderoso como Core ... Pero es muy estable y consistente desde 2.0.

Solo es mi opinión.

Hola @suncodefactory ,
Recuerdo que hace algún tiempo cuando la gente le gritó a ms por no usar bibliotecas de código abierto, ahora se les culpa por hacerlo: D
¡Desde mi punto de vista, la API de Aspnet / core MVC ha sido muy estable desde mvc1 / 2! La razón por la que aspnet se mantuvo estable desde 2.0 fue que nunca cambió / mejoró en absoluto 😄.
Para ser honesto, si está utilizando una función avanzada de una biblioteca de serialización, tiene la oportunidad de repensarla y tal vez abordar el problema con una estructura de datos adecuada para la tarea, en lugar de pretender que todos los serializadores admiten todas las funciones del lenguaje, en mi opinión, es el problema incorrecto para resolver y la forma incorrecta de utilizar la serialización.
La claridad, la compatibilidad con versiones anteriores y las extensiones futuras son lo que impulsan mis dtos serializables, compensaciones muy diferentes utilizadas en objetos lógicos comerciales comunes (son privados, tienen muchas funciones, etc.)

Podemos mover microservicios de net framework a Linux (net core) sin casi ningún esfuerzo por parte de los equipos de productos. No sé de qué están hablando. Microsoft está haciendo un gran trabajo acelerando la implementación de cambios como este que se habían retrasado mucho.

Hola @suncodefactory ,
Recuerdo que hace algún tiempo cuando la gente le gritó a ms por no usar bibliotecas de código abierto, ahora se les culpa por hacerlo: D

Para mí, el punto no se trata de bibliotecas de terceros ... Se trata de diseño arquitectónico que en este caso particular falta o simplemente está mal.

Además, nunca hablé del clásico asp.net ... Estaba hablando de .NET Framework 2.0. Y la razón por la que fue estable no fue porque no hubo mejoras como afirma falsamente (ya que .net core está basado en .NET 4.6.1). La razón fue porque estaba bien planeado y diseñado.

En cuanto a lo bueno que es aspnet core frente al clásico asp.net mvc que no tiene nada que ver con este hilo en particular.

Este hilo trata sobre un cambio radical que MS está a punto de lanzar una vez más sin pensarlo a fondo.

Podemos mover microservicios de net framework a Linux (net core) sin casi ningún esfuerzo por parte de los equipos de productos. No sé de qué están hablando. Microsoft está haciendo un gran trabajo acelerando la implementación de cambios como este que se habían retrasado mucho.

Cambios como este no deberían estar sucediendo en absoluto ..... ¿Así que estás contento con los cambios importantes?

Y decir que el equipo central de asp.net ha estado haciendo un gran trabajo en los cambios de envío simplemente no es cierto.

He estado desarrollando con asp.net core desde beta 3 y estoy bastante seguro de que falta el proceso de diseño arquitectónico.

En cuanto a lo bueno que es el núcleo de asp.net frente al clásico ... no tengo objeciones, ya que creo que es mejor que el clásico.

Pero el hecho de que asp.net core sea mejor que el clásico no significa que estén haciendo un gran trabajo en el diseño de arquitectura. Esos dos son temas completamente diferentes.

¿Podemos limitar esta discusión a la funcionalidad JSON en .NET Core 3, por favor?

Cambios como este no deberían estar sucediendo en absoluto ..... ¿Así que estás contento con los cambios importantes?

Entonces, ¿no se deben realizar mejoras? ¿Por qué eres un programador si no quieres que el software evolucione, crezca y mejore?

@suncodefactory

Cambios como este no deberían estar sucediendo en absoluto ..... ¿Así que estás contento con los cambios importantes?

Ah, vamos, lo haces sonar como "romper el cambio" significa que tienes que desechar tu proyecto y empezar de cero.

¿Cuántos cambios importantes puede contar que hubo en ASP.NET Core 2.x / 3.0 que requirieron más de

• Hacer referencia a un paquete diferente
• Usando un espacio de nombres diferente
• Cambiar más de 5 líneas de código
• Eliminando 1-2 líneas de código (es decir, Propiedades de las clases de Opciones)

??

@suncodefactory

Este hilo trata sobre un cambio radical que MS está a punto de lanzar una vez más sin pensarlo a fondo.

¿Cómo es esto realmente un cambio revolucionario? Las nuevas API JSON son un conjunto completamente nuevo de API que se introducen en .NET Core y que no eliminan ni rompen ningún elemento existente. Sí, verá que las cosas y las bibliotecas cambiarán a él eventualmente, ya que ofrece diferentes oportunidades de optimización, pero no está obligado a aplicar eso a su código.

Hablando de ASP.NET Core en particular, aunque _ "eso no tiene nada que ver con este hilo en particular" _, tiene la opción de seguir usando Newtonsoft.Json si depende de algunas de sus características más avanzadas. Sí, tendrá que cambiar algún código para que funcione, pero no considero que eso realmente se rompa teniendo en cuenta que solo tiene que hacerlo si realmente desea actualizar a la nueva versión. Eso es lo bueno ahora: tienes más opciones.

Si no le gusta esto por alguna razón, entonces siéntase libre de ceñirse a .NET Framework, que es un conjunto de características conocidas, estables y fijas. Eso permanecerá allí durante bastante tiempo, por lo que puede depender totalmente de eso. Pero por favor deje de usar este hilo para difundir su agenda anti-cosas nuevas cuando _ "eso no tiene nada que ver con este hilo en particular" _.

Dos preguntas de un usuario de EF Core.

1. ¿ System.Text.Json admitirá referencias circulares? Las referencias circulares pueden ocurrir en los datos de EF Core donde hay vínculos de navegación en ambos sentidos entre las clases. Json.NET maneja esto con configuraciones como
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. Con el auge de las clases de estilo DDD con establecedores privados y constructores privados, ¿puede System.Text.Json deserializar este tipo de clases?

@JonPSmith En mi opinión, no debería importar. Nunca deberías serializar una entidad directamente. Debe serializar una proyección. Esto evita referencias circulares y no expone todos los datos, especialmente cuando agrega más propiedades a la entidad que pueden terminar siendo confidenciales.

@JonPSmith : En mi opinión, ambos casos de uso no son válidos tanto desde el punto de vista de las mejores prácticas como de la DDD.

1. Nunca he visto una mejor práctica que recomiende deserializar entidades directamente (excepto en los ejemplos de tutoriales más simples). Las referencias circulares siempre tienen un costo. Requiere el seguimiento de objetos ya procesados, es decir: asignaciones de memoria y ciclos de CPU adicionales. Pero uno de los objetivos de correo de la nueva biblioteca JSON es evitar exactamente estas asignaciones de memoria
2. No es válido también, ya que nunca serializa en un modelo de dominio, especialmente cuando obtiene los datos a través de una solicitud web, como una llamada WebApi. En DDD siempre debe trabajar con eventos / comandos, enviar el comando a su aplicación web, obtener (y deshidratar) la entidad del repositorio (a través del mapeo ORM o EventSourcing), aplicar el comando, persistirlo.

Además de eso, la nueva API JSON es para escenarios de alto rendimiento. Para todo lo demás en el que necesite un conjunto completo de funciones, usted (y debería) seguir usando JSON.NET o lo que sea que satisfaga sus necesidades.

@suncodefactory Esto es lo opuesto a un cambio

Por ejemplo, mire Microsoft.Extensions.Configuration.Json 2.2.0 ; tiene una dependencia de Newtonsoft.Json 11.0.2. Ese es un paquete de configuración; nada que ver con el manejo de solicitudes HTTP o ASP.NET Core MVC. O mire Microsoft.IdentityModel.Protocols.OpenIdConnect , que lo usa para manejar JSON Web Tokens; ese es un camino caliente que necesita tanto rendimiento como sea posible. JSON.NET no es una biblioteca lenta bajo ningún estándar, pero logra un equilibrio entre rendimiento, riqueza de funciones y soporte para una amplia gama de escenarios de usuario. La nueva biblioteca JSON de Microsoft no necesita hacer eso, porque JSON.NET existe. Para que pueda concentrarse en manejar los conceptos básicos absolutos con el máximo rendimiento.

.NET siempre ha tenido su propia solución de serialización JSON en System.Runtime.Serialization.Json , pero en el mundo de alto rendimiento de .NET Core no es muy buena. Ciertamente no querría que se invocara para verificar las credenciales en cada solicitud entrante. Una nueva biblioteca JSON, con manejo de datos UTF-8 moderno y asignaciones mínimas, es muy bienvenida.

Aún podrá hacer referencia a Newtonsoft.Json en su aplicación y continuar usándolo como la canalización de deserialización / serialización para los datos de solicitud / respuesta como antes. Y a partir de ahora, podrá hacerlo sin preocuparse por la versión de la que depende el framework Core. Eso es una victoria para todos.

Gracias @ phillip-haydon y @TsengSR por sus pensamientos. Le preguntaba si estas funciones serían compatibles y usted dice que no lo son, lo que entiende y acepta. Continuaré usando Json.NET para el caso en el que necesite serializar / deserializar clases de EF Core.

POR CIERTO. Tengo una razón válida para serializar / deserializar clases de entidad EF Core de estilos DDD. Tengo una biblioteca que contiene una función que llamo Seed from Production que permite a los desarrolladores tomar una instantánea de los datos de una base de datos de producción, anonimizar cualquier dato privado y luego generar una nueva base de datos con la instantánea.

Necesitaba esta función para uno de mis clientes y, en lugar de escribir solo para ellos, la incorporé a mi biblioteca de código abierto EfCore.TestSupport para que otros puedan usarla (y mi cliente no tuvo que pagarme por ello).

¿Existe un plan para apoyar a [DataContract] , [DataMember] y amigos?

Hoy en día, esta es una forma de definir cómo se deben serializar / deserializar los tipos (por ejemplo, el nombre del campo) de una manera que no genere una dependencia de ninguna biblioteca de serialización en el proyecto que la usa.

El actual JsonNamingPolicy toma una cadena, por lo que no hay forma de inspeccionar los atributos del miembro.

Hola.
Intentamos cambiar nuestros microservicios a DotNet core 3 preview 6 y no podemos deserializar nuestros tipos de referencia inmutables: clase con propiedades inmutables (sin setters) y solo un constructor para establecer todas las propiedades. Json.net maneja correctamente estas clases.
¿Es este un problema de la necesidad de la API System.Text.Json o es un plan para respaldarlo?
Gracias por sus respuestas

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

Gracias @khellang.
De hecho, el soporte está planeado, pero no para la versión 3.0.
Parece que es posible continuar usando Json.net con DotNet core 3 pero no sé cómo hacerlo (agregar la referencia del paquete no es suficiente). ¿Hay una manera de hacerlo?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

gracias por su ayuda chicos.
Funciona !
Me perdí la guía de migración donde se explica todo:

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

En mi opinión, json.net está a medio preparar y convertirlo en el predeterminado (es decir, para el señalizador) que rompe el código existente fue prematuro.

Por otro lado, migrar de .NET Core 2.2 a 3.0 es una actualización de versión importante e incluso si el equipo de .NET Core no sigue estrictamente el control de versiones semántico, esperaría que las cosas se rompan al actualizar de una versión a otra sin cambios explícitos. (como agregar explícitamente la biblioteca de Newtonsoft en la tubería)

El cierre dado que esto es un anuncio y no un problema.

Aunque la comunidad tiene muchas voces en contra de la mejora, como nuevo marco de alto rendimiento, la mala velocidad es inaceptable.

Sé que se ha dicho antes, pero también me gustaría agregar mi deseo.

Sería realmente asombroso si pudiéramos tener objetos inmutables. Sé que es posible agregando Json.NET al MVC-Pipeline, pero en mi caso todas mis pruebas fallan ya que estoy usando ReadAsAsync<> que ahora se implementa en algún lugar de una dependencia de pares de Microsoft.AspNet.WebApi.Client y eso se basa en System.Text.Json

Proporcionamos la biblioteca .NET Standard Class a los clientes para que puedan usar nuestra biblioteca para trabajar en cualquier plataforma que admita .NET Standard. Necesitamos usar System.Text.Json en nuestra biblioteca de clases. ¿Cuál será el plan para admitir System.Text.Json en .NET Standard?

@alsami

Sería realmente asombroso si pudiéramos tener objetos inmutables.

¿Solo necesita la capacidad de evitar que otros lo muten o también necesita la capacidad de crear nuevas instancias con partes que se reemplazan de manera inteligente (como colecciones inmutables y Roslyn)? Si necesita lo primero, lo tenemos cubierto con las próximas API JsonDocument DOM.

@ mwoo-o

¿Cuál será el plan para admitir System.Text.Json en .NET Standard?

Está disponible como paquete NuGet para .NET Standard 2.0: System.Text.Json .

@terrajobst

Gracias. ¿Cuándo se incluirá este System.Text.Json en .NET Standard SDK?
¿El estándar .NET 3.0 (o alguna otra versión posterior) incluirá el paquete System.Text.Json? ¿Ocurrirá en la versión de producción del SDK de .NET Core 3.0?

@terrajobst

¿Hay planes para hacer que el método Deserialize funcione con PipeReader? O agregue el método Patch que se puede usar en escenarios de transmisión en los que no tenemos todos los datos cuando comenzamos la deserialización.

Aquí hay una versión simplificada de la API propuesta:

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

capacidad para evitar que otros lo muten

Solo esto actualmente. Realmente es solo para 'objetos de transferencia de datos'. ¡Una gran noticia!

@ mwoo-o

Gracias. ¿Cuándo se incluirá este System.Text.Json en .NET Standard SDK?
¿El estándar .NET 3.0 (o alguna otra versión posterior) incluirá el paquete System.Text.Json? ¿Ocurrirá en la versión de producción del SDK de .NET Core 3.0?

No hay .NET Standard SDK. .NET Standard es una superficie API, disponible en todas las plataformas compatibles. Puede enviar System.Text.Json en cualquier aplicación que se ejecute en las plataformas compatibles con el estándar .NET; consulte Soporte de implementación de .NET .

@TsengSR

No hay .NET Standard SDK. .NET Standard es una superficie API, disponible en todas las plataformas compatibles.

Bueno, hay un tipo de proyecto que te permite usar las API. Creo que @ mwoo-o está preguntando si tenemos planes de agregar System.Text.Json a .NET Standard. La respuesta es no. Bien, ahora estamos planeando dejar esto para que sea un paquete NuGet.

Es terrible Demasiadas pocas funciones para aplicar en el proyecto.