Runtime: L'avenir de JSON dans .NET Core 3.0

C'est bien. Je suis tout à fait pour une analyse json plus rapide et moins allouée.

Y aura-t-il une discussion sur les fonctionnalités de json.net que la nouvelle API json prendra en charge ? Si c'est le cas, je pense que les deux principales caractéristiques qui me viennent à l'esprit seraient le renommage/la casse des propriétés et l'ignorance des propriétés nulles.

Y aura-t-il une discussion sur les fonctionnalités de json.net que la nouvelle API json prendra en charge ?

Oui. Nous avons pensé très tôt à migrer vers CoreFx. Ce sera une fonctionnalité qui est conçue et construite à l'air libre comme d'habitude. De plus, j'ai contacté les auteurs de nombreuses bibliothèques JSON populaires et les ai invités à revoir les premières versions de cette annonce. J'espère que nous pourrons travailler ensemble pour créer un composant JSON solide pour la plate-forme tout en gardant l'écosystème au-dessus de celui-ci (comme ASP.NET Core) enfichable pour permettre à d'autres. En fin de compte, différents consommateurs auront des objectifs différents et la possibilité de brancher une bibliothèque différente signifie que vous pouvez obtenir une flexibilité maximale dans le choix du composant qui présente le meilleur rapport coût/bénéfice pour votre application.

Salut @terrajobst. Le nouveau JSON apparaîtra-t-il comme une surface API netstandard, ou simplement intégré dans Core pour le moment ?

Salut @terrajobst. Le nouveau JSON apparaîtra-t-il comme une surface API netstandard, ou simplement intégré dans Core pour le moment ?

Oui, la question est de savoir quel train de libération il peut attraper. 2.1 est peut-être trop tôt.

Ainsi, les bits d'analyse JSON intégrés au framework devraient être disponibles lorsque la v3.0 passera à RTM ou seule l'intégration Apis dans ASP.NET Core sera complète (avec une seule implémentation - JSON.NET) qui sera permutable à un date ultérieure?

Le plan pour 3.0 est le suivant :

1. API JSON hautes performances intégrées. Lecteur/enregistreur de bas niveau, un lecteur/enregistreur basé sur Stream et un sérialiseur.
2. ASP.NET Core est enfichable par rapport au composant JSON.

Il y a une question ouverte sur ce que les modèles pour ASP.NET en 3.0 utiliseront. En fonction de la fidélité que nous pouvons fournir par 3.0, nous pourrions les faire intégrer le package d'intégration Json.NET. Cependant, l'objectif est de fournir suffisamment de fidélité et de parité pour ne dépendre que de celles intégrées par défaut.

Merci - cela aide à clarifier les choses. ??

Et quelques questions supplémentaires !

Si un package d'intégration est utilisé, sera-t-il utilisé dans l'ensemble du pipeline ASP.NET Core ou uniquement à certains endroits ?
Je suppose que Kestrel utilisera toujours les lecteurs/écrivains internes.

L'ergonomie de l'Api serait-elle :

• Fournissez une intégration uniquement lorsque vous souhaitez améliorer l'ensemble de fonctionnalités intégrées.
• Fournissez toujours un package d'intégration, mais un serait intégré, intégrant les lecteurs/enregistreurs de bas niveau dans des fonctionnalités de niveau supérieur.

En supposant que ce nouvel analyseur sera utilisé pour tous les éléments JSON intégrés tels que appSettings.json , pourrais-je faire une demande anticipée pour que les commentaires soient pris en charge ?

Merci.

C'est une super nouvelle ! Question rapide : de quels packages dépendra cette bibliothèque ?

Pourquoi réinventer une roue testée par les clients de production ? S'il y a un problème avec Json.Net, envoyez simplement un PR car il est open source.

Je suppose que le problème avec Json.NET est qu'il n'appartient pas à Microsoft, il doit donc être remplacé. Oh mais il y en a déjà un dans System.Runtime.Serialization, appelé DataContractJsonSerializer. Pouvez-vous l'utiliser, ou est-ce si amusant de coder de nouvelles API, du bricolage, que cela ne peut être évité ?

La raison pour laquelle je ne suis pas très satisfait de cela est que Json.Net prend déjà en charge les cas extrêmes comme, par exemple, les unions discriminées F#. Pas particulièrement bien, mais à un niveau que les développeurs peuvent vivre avec ça. Au lieu de cela, toute nouvelle API oublie généralement autre chose que le cas d'utilisation d'un site Web ASP.NET.

@markrendle Il existe un paramètre d'activation sur JsonReader (travail en cours) pour autoriser les commentaires. Le système de configuration activera probablement ce paramètre par défaut.

@Thorium Avez-vous réellement lu le PO? Cela explique pourquoi pas JSON.NET, et que JSON.NET continuera d'être officiellement pris en charge avec un package de complément.

@JamesNK 😄

@Thorium Json.NET ne va pas disparaître. Vous ne perdez rien. Il s'agit d'une autre option pour les scénarios simples et performants.

@Thorium Json.NET ne va pas disparaître. Vous ne perdez rien. Il s'agit d'une autre option pour les scénarios simples et performants.

Comment le Json généré sera-t-il rétrocompatible ?

Par exemple, j'utilise SignalR qui utilise Json.NET en arrière-plan. Maintenant, mes unions discriminées F# seront-elles sérialisées dans des structures similaires afin que je ne me heurte pas à des problèmes avec le nouveau service Azure Signalr (fond de panier) qui lance des exceptions d'exécution en raison de la sérialisation des structures différemment de la bibliothèque SignalR actuelle de mon serveur ?

J'espère que d'autres adopteront rapidement les nouvelles API. En te regardant ,

Envisagez-vous d'inclure une classe comme JObject et la prise en charge de la dynamique ou cela est-il hors de portée pour cette fonctionnalité ?

Je recommande de regarder dans l'une de ces bibliothèques :

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

cela pourrait être un très bon moyen de trouver des inspirations.

DataContractJsonSerializer aura-t-il ce nouveau lecteur/enregistreur utilisé en interne ?

J'ai contacté les auteurs de nombreuses bibliothèques JSON populaires et les ai invités à revoir les premières versions de cette annonce. J'espère que nous pourrons travailler ensemble pour créer un composant JSON solide pour la plate-forme tout en gardant l'écosystème au-dessus de celui-ci (comme ASP.NET Core) enfichable pour permettre à d'autres.

Y a-t-il une raison pour laquelle la 2e bibliothèque JSON la plus populaire après JSON.NET - ServiceStack.Text qui a déjà été refactorisée pour être construite sur SpanApis a été exclu ? Les sérialiseurs ServiceStack.Text sont utilisés pour alimenter ServiceStack, l'un des "cadres Web compatibles avec .NET Core alternatifs" les plus populaires qui prend en charge l'exécution sur davantage de plates-formes dans .NET . Je suis curieux de savoir à quel « écosystème » vous faites référence et avec lequel vous espérez « travailler ensemble » ici ? Je serais évidemment intéressé par la compatibilité de ces API "enfichables" ou si cela finit par être un autre domaine où l'adoption et l'intégration de nouvelles bibliothèques MS finissent par tuer l'écosystème qu'elles remplacent.

Cela peut valoir la peine d'examiner la haute performance sous licence MIT https://github.com/neuecc/Utf8Json

C'est certainement ce dont nous avons besoin... ma suggestion pour le nom de la classe principale, utilisez simplement " Json ".

@terrajobst, je me demandais quand cela arriverait...

Je me suis toujours demandé pourquoi JSON.Net avait été ajouté en tant que dépendance directe plutôt qu'abstraction (même en considérant qu'il s'agit du package JSON de facto pour l'écosystème .Net).

Cependant, je pense qu'ajouter une abstraction pour JSON uniquement est en quelque sorte une prise de vue sur vos pieds. Je pense qu'une abstraction _serializer_ comme celle que nous avons à Orléans IExternalSerializer sous la forme de Microsoft.Extensions.Serialization ou quelque chose serait plus efficace...

Y a-t-il une raison particulière pour laquelle make est uniquement JSON ? Je vois d'autres cas où les gens peuvent brancher d'autres types de sérialiseurs...

@galvesribeiro Quelque chose comme IOutputFormatter / IInputFormatter ?

@yaakov-h n'était pas au courant de ceux-ci... Le sont-ils ?

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

D'accord... ça a du sens maintenant. Alors, où ces _nouvelles_ abstractions uniquement JSON entrent en jeu ?

La décision de lancer cette entreprise témoigne également de l'inefficacité de System.String (UTF-16 String).
Je pense que les nouveaux hooks JSON qui résumeront toute la gestion de json entre asp.net et une bibliothèque json seraient nettement meilleurs si vous vous attaquiez à la tâche de créer d'abord une chaîne utf-8 BaseType.
--> Peut-être créer un System.Utf8String

Ouais... Je me souviens que @migueldeicaza a dit il y a quelque temps qu'un jour, il ferait en sorte que .Net utilise des chaînes utf8 😄

@jges42 @galvesribeiro La proposition d'ajouter Utf8String est https://github.com/dotnet/corefx/issues/30503. Il semble qu'il soit également prévu pour .Net Core 3.0.

Ces nouvelles API JSON auront-elles des chemins de code dédiés à la fois pour Utf8String et char / string , ou l'optimisation implique-t-elle de renverser le statu quo, de sorte que tout ce qui n'est pas UTF-8 devra être transcodé à la place ? (Cela n'implique pas nécessairement un coût énorme puisque presque rien n'est l' UCS-2 UTF-16 natif de string et doit encore être adapté/comptabilisé, j'essaie juste de me faire une idée du Surface de l'API. Faire cela pour que Kestrel soit plus efficace est raisonnable ; j'espère juste que la conception prend en compte plus de clients que Kestrel.)

@galvesribeiro
En fait, je pense que vous soulevez un bon point. Je pense que la création d'un framework de sérialisation efficace et d'un décodeur/encodeur Json efficace sont deux types de problèmes. Je sais qu'il existe des moyens de marquer une structure comme sérialisable, mais je ne l'ai jamais vue utilisée pour une sérialisation Json.

Le projet Serde de Rust a en fait un bon concept en divisant le problème en 2 problèmes :

1. Sérialiser/désérialiser (traits similaires aux interfaces en C#), ce qui signifie que tout type qui hérite de cette interface peut être sérialisé/désérialisé
2. Le sérialiseur/désérialiseur est l'implémentation spécifique au format.

Un type peut implémenter Serialize/Deserialize à la main ou par une macro (qui pourrait être considérée comme une forme de plug-in de compilateur) qui génère le code nécessaire pour implémenter ces caractéristiques. Si un type contient un type enfant qui n'implémente pas ces traits, il avertira même au moment de la compilation. C'est un bon concept dans l'ensemble car cela signifie que vous pouvez simplement écrire des objets de données et les (dé)sérialiser pour n'importe quel format pris en charge. L'écriture d'un format est beaucoup plus facile de cette façon.

Je ne pense pas que les méthodes de Serde fonctionneront toutes pour C#, car elles n'offrent pas vraiment d'attributs spécifiques à un type qui pourraient être importants pour certaines structures de données. Il doit donc y avoir du travail pour cela. Considérant également AoT Compilation sera très important pour certains projets (WASM) Il devrait également bien fonctionner avec It.

Voici un lien vers la documentation Serde pour le rendre plus clair (Cliquez sur les 4 traits du bas pour voir le concept):
https://docs.serde.rs

@mythz La licence de ServiceStack.Text est AGPL avec quelques exceptions FOSS - cela empêcherait probablement les gens de l'utiliser dans un logiciel propriétaire. De plus, je pense qu'il faut une autorisation légale pour que les employés de Microsoft y touchent même, et tout employé qui a consulté la source pourrait se voir interdire de travailler sur toute autre bibliothèque JSON ou technologie connexe.

@poizan42 ServiceStack.Text est sous double licence avec des licences OSS/commerciales libres d'utilisation dans les projets commerciaux OSS et à source fermée. Mais les licences de code source ne sont pas pertinentes car MS développe sa propre implémentation.

L'affirmation était que MS collaborait avec "l'écosystème" pour développer des API de sérialisation JSON "enfichables" - si ServiceStack, qui est en développement actif depuis près d'une décennie, est l'une des rares suites logicielles .NET indépendantes à avoir réussi à maintenir son propre communauté saine indépendante en dehors de MS au cours de sa durée de vie, qui maintient le 2e sérialiseur JSON le plus populaire après JSON.NET et ce qui semble être le 2e Framework Web le plus populaire développé activement (en dehors de MS), qui s'exécute sur plus de plates-formes que n'importe quel MS framework web n'est pas considéré comme faisant partie de "l'écosystème" qui est principalement affecté par ces changements, je suis curieux de savoir à quel "écosystème" ils font référence et pourquoi nous sommes exclus et combien d'autres sont exclus parce qu'ils sont pas considéré comme faisant partie de "l'écosystème".

Je ne comprends pas tout ce ressentiment. Asp.net vous a obligé à utiliser une version spécifique de json.net. Ils le modifient pour que vous puissiez choisir l'analyseur JSON que vous voulez (ou le mélanger), et il y a un OOB par défaut. ServiceStack devrait être heureux de ce changement et surveiller et fournir des commentaires sur ce développement, plutôt que de simplement se plaindre de la façon dont il a été négligé, ce qui est rarement un moyen efficace de favoriser un bon esprit de communauté. Je connais personnellement de nombreux membres de l'équipe .net et je suis convaincu qu'ils n'avaient aucune intention malveillante. Ils sont tous de grands partisans des logiciels libres et du travail communautaire.
Personnellement, toute licence dérivée de la GPL serait un grand non automatique pour moi. Apache ou MIT pour moi et mes clients ou nous passerons à autre chose. Pas de mystérieuses doubles licences.

Asp.net vous a obligé à utiliser une version spécifique de json.net

Nan. Comment?

Je ne comprends pas tout ce ressentiment.

Secondé !

Je suis personnellement heureux que nous puissions enfin utiliser le sérialiseur de notre choix sans avoir à télécharger JSON.Net uniquement pour ne pas l'utiliser, mais encore besoin de l'expédier car ASP.Net a une référence matérielle à la bibliothèque.

(Prise sans vergogne : https://github.com/gregsdennis/Manatee.Json)

@dotMorten

Je ne comprends pas tout ce ressentiment.

Parce que vous n'avez pas lu ou compris mes commentaires. Essayez de répondre directement à mes commentaires (c'est-à-dire utilisez la fonction de citation) au lieu de créer votre propre récit.

Ils le modifient pour que vous puissiez choisir l'analyseur JSON que vous voulez (ou le mélanger)

Ainsi, comme un "mélange" magique, ils choisiront automatiquement les options d'API et de plugabilité les plus optimales que les sérialiseurs .NET existants pourront brancher directement et mélanger dans leurs options de personnalisation internes, le format filaire étant exactement le même chose et tout va fonctionner sur tous les sérialiseurs ? Dans ce cas, vous avez raison, aucun test de collaboration ou d'intégration n'est nécessaire avant que les API ne soient solidifiées. Ou peut-être que les implémentations du sérialiseur sont plus nuancées avec diverses différences et opinions et que tout ne fonctionnera pas, toutes les options de personnalisation ne seront pas implémentées exactement, le format filaire ne sera pas le même et il ne sera pas possible d'y parvenir interopérabilité parfaite entre les différentes implémentations. La "plugabilité" que vous passez sous silence fait une grande différence qui peut déterminer l'ampleur de la réécriture que nous devrons faire et s'il sera ou non possible de prendre en charge l'implémentation existante et cette nouvelle implémentation.

ServiceStack devrait être heureux de ce changement et surveiller et fournir des commentaires sur ce développement,

Ce que nous n'avons pas eu l'occasion de faire (ou que nous savons toujours faire), mais merci de m'avoir fait savoir comment je devrais me sentir. Je préférerais évaluer la fonctionnalité, l'interopérabilité et la compatibilité de la bibliothèque avant de pouvoir évaluer la force de chacune. Ce sera peut-être génial et il sera facile de prendre en charge les deux implémentations, mais d'après l'expérience, l'interopérabilité avec différentes implémentations de sérialiseur est semée d'incompatibilités et de cas particuliers et de dépendance à différentes implémentations et fonctionnalités spécifiques à la sérialisation. Ma prédiction est que l'interopérabilité entre JSON.NET et l'impl par défaut sera excellente car c'est leur objectif de conception et ce qui est testé, mais les autres sérialiseurs ne seront pas aussi chanceux.

plutôt que de se plaindre de la façon dont il a été négligé, ce qui est rarement un moyen efficace de favoriser un bon esprit communautaire.

Je conteste leur affirmation selon laquelle ils ont développé cela en collaboration avec "l'écosystème". ici (j'ai du mal à me souvenir d'une époque où le regroupement d'un défaut a déjà aidé l'écosystème). Mais quoi qu'il en soit, nous devons développer une intégration transparente avec tout ce qu'ils publient auquel j'aimerais pouvoir avoir accès et entrer avant que les API ne soient gelées. Mais ce n'est pas grave, je ne m'attends pas à ce que vous vous souciiez de la façon dont cela affecte les frameworks/bibliothèques existants qui doivent prendre en charge les implémentations existantes et futures, vous n'êtes probablement concerné que si JSON.NET reste pris en charge ou non parce que c'est tout ce qui vous affecte, mais essayez de conserver vos hypothèses et de nous faire savoir ce que nous devrions ressentir pour absorber des changements perturbateurs comme celui-ci.

J'ai du mal à me souvenir d'une époque où le regroupement d'un défaut a déjà aidé l'écosystème

Oh, allez !

(Pour le reste, je suis plutôt d'accord avec vos sentiments)

@mythz Je suis surpris que cela pose des problèmes puisque nous

Ma prédiction est que l'interopérabilité entre JSON.NET et l'impl par défaut sera excellente car c'est leur objectif de conception et ce qui est testé, mais les autres sérialiseurs ne seront pas aussi chanceux.

Je peux déjà vous dire que ce que nous expédierons ne prendra pas en charge la gamme de fonctionnalités prises en charge par JSON.NET. Ce n'est donc déjà pas vrai et en fait, nous nous attendons à ce qu'il soit moins capable dans certains cas (pour des raisons de performances et de portée).

La connectabilité existe déjà aujourd'hui et nous avons des implémentations JSON.NET par défaut partout. Cela change simplement cette valeur par défaut pour être le nouveau sérialiseur JSON à la place ...

@abatishchev

Je ne m'en souviens vraiment pas, quand l'intégration ou l'adoption d'une implémentation par défaut dans leur cadre de base (ou leurs projets) a-t-elle profité à l'écosystème environnant existant ? Chaque fois que je l'ai vu groupé, par exemple NuGet, MVC, ORM, tests unitaires, API Web, etc., cela n'a jamais eu qu'un effet néfaste, prenant efficacement l'oxygène et la motivation pour rivaliser dans cet espace.

Il y a des moments comme où des bibliothèques concurrentes comme ASP.NET Ajax n'ont pas réussi à rivaliser où elles ont fini par l'abandonner et ont adopté jQuery, mais je ne me souviens pas d'un moment où cela a jamais aidé? Remarque : il ne s'agit que de mon observation en suivant de près .NET après plusieurs années, peut-être qu'il existe des exemples et je serais curieux d'en connaître certains ? mais à partir de mon POV, les effets des valeurs par défaut de MS ont un effet néfaste sur l'écosystème existant de fonctionnalités qu'il remplace.

Les avantages de

Mais n'inondatons pas et ne restons pas sur le sujet. À votre santé!

@davidfowl Cela change simplement cette valeur par défaut pour être le nouveau sérialiseur JSON à la place ...

Je voudrais proposer qu'il n'y ait pas de sérialiseur par défaut et exiger qu'une implémentation soit téléchargée. S'il doit y avoir une valeur par défaut, sera-t-elle intégrée au framework ou à une bibliothèque distincte (comme c'est le cas actuellement) ?

Je voudrais proposer qu'il n'y ait pas de sérialiseur par défaut et exiger qu'une implémentation soit téléchargée. S'il doit y avoir une valeur par défaut, sera-t-elle intégrée au framework ou à une bibliothèque distincte (comme c'est le cas actuellement) ?

C'est déraisonnable car l'expérience sera médiocre. Chaque plate-forme moderne intègre JSON.

@davidfowl Ne cause pas de problèmes maintenant car il n'est pas publié, mais nous devons toujours évaluer les perturbations et l'étendue du travail que cela va causer. Combien d'efforts faudra-t-il pour le prendre en charge de manière transparente, serons-nous en mesure d'appliquer des personnalisations au nouvel impl pour prendre en charge notre comportement existant, serons-nous en mesure de prendre en charge le nouveau modèle de personnalisation et les API, sommes-nous en mesure de personnaliser notre sérialiseur pour prendre en charge la configuration/format filaire par défaut permettra aux nouvelles API de prendre en charge à la fois .NET Core et .NET Framework - s'il est clair qu'ASP.NET Core 3 abandonnera .NET Framework, il n'est pas clair si les nouvelles API vont utiliser . NET Core uniquement des types qui nous empêcheront de continuer à prendre en charge à la fois .NET Core et .NET Framework.

Je peux déjà vous dire que ce que nous expédierons ne prendra pas en charge la gamme de fonctionnalités prises en charge par JSON.NET. Ce n'est donc déjà pas vrai et en fait, nous nous attendons à ce qu'il soit moins capable dans certains cas (pour des raisons de performances et de portée).

Je m'attends seulement à ce qu'il prenne en charge un sous-ensemble de fonctionnalités JSON.NET, par exemple, JSON.NET prendra-t-il en charge le format filaire par défaut ? (je suppose que oui). Le nouvel impl adoptera-t-il les formats de sérialisation JSON.NET dans la mesure du possible (en supposant également que oui).

Combien d'efforts faudra-t-il pour le prendre en charge de manière transparente, serons-nous en mesure d'appliquer des personnalisations au nouvel impl pour prendre en charge notre comportement existant, serons-nous en mesure de prendre en charge le nouveau modèle de personnalisation et les API, sommes-nous en mesure de personnaliser notre sérialiseur pour prendre en charge la configuration/format filaire par défaut permettra aux nouvelles API de prendre en charge à la fois .NET Core et .NET Framework.

@mythz Je ne suis pas en partie ça. J'essaie de comprendre à quel point cela discute des API existantes par rapport à la façon dont elles vont être consommées. Peut-être pourrions-nous envisager des scénarios concrets ?

@mythz, la seule vraie préoccupation que je vois pour servicestack serait si cette nouvelle API n'est pas prise en charge sur .net framework classic, de cette façon servicestack ne pourra pas prendre en charge à la fois .net core et .net classic, en tant que client, packages en fonction de ces bibliothèques, ils ne seront pas disponibles dans le framework .net full . Est-ce votre souci ? Je demande parce que votre préoccupation en tant qu'exemple concret n'est pas claire.

Il s'agit également d'une proposition à son stade initial et l'objectif qu'elle souhaite atteindre semble assez prometteur. La critique constructive est toujours bonne pour tous les projets d'oss.

Les avantages de

Par écosystème, je fais référence à l'écosystème / aux communautés de la bibliothèque .NET environnante (qui est probablement aussi "l'écosystème" dans le PO) qu'il remplace et que je dirais également que les utilisateurs de .NET bénéficient également d'un écosystème sain avec une variété d'options et plus de concurrence (comme c'est le cas des écosystèmes plus sains comme Python, Java, Node, Ruby, PHP, etc.).

EF est le meilleur ORM du monde .NET

Peu de temps après la sortie d'EF, il a rapidement pris la majorité des parts de marché ORM tout en étant plus de 6 fois plus lent que NHibernate tout en prenant sans doute en charge moins de fonctionnalités, extrait de mon interview InfoQ 2012 :

Leur dernière tentative de couche d'accès aux données ORM dans Entity Framework a également eu un impact négatif sur la communauté autrefois florissante d'ORM NHibernate. Bien qu'il soit plusieurs fois plus lent que tous les autres ORM Open Source .NET , EF a réussi à attirer plus de téléchargements que tous les autres ORM combinés.

Gardez à l'esprit que c'était avant .NET Core où les performances sont désormais une priorité absolue, mais c'est un exemple historique de l'effet néfaste que les valeurs par défaut de MS ont sur les écosystèmes/communautés existants. OMI, il est à peu près accepté ce qui arrive aux communautés existantes lorsque MS introduit des valeurs par défaut, c'est pourquoi il y a eu récemment un recul pour revenir aux valeurs par défaut d'expédition qui concurrencent IdentityServer et AutoMapper.

et MSTest était meilleur que NUnit à l'époque.

IMO, cela ne l'a jamais été (et la prise en charge de R# de NUnit a toujours été excellente AFAICR) et le fait que nous ne puissions pas l'exécuter sur plusieurs plates-formes sur Mono signifiait que les bibliothèques prenant en charge plusieurs plates-formes sur Mono (avant .NET Core) ne pouvaient pas être utilisées ce.

Mais n'inondatons pas et ne restons pas sur le sujet. À votre santé!

Je ne veux pas non plus détourner ce fil à ce sujet, mais je devais expliquer pourquoi je ne suis pas d'accord avec vos points.

Par rapport à cela, la principale raison d'utiliser maintenant un sérialiseur différent de JSON.NET est la performance et étant donné la raison de ce nouveau sérialiseur par défaut est la performance. Étant donné que la plupart des gens n'utilisent que les valeurs par défaut, je m'attends à ce que cela ait l'impact le plus notable sur le partage JSON.NET, tandis que la principale raison d'utiliser un sérialiseur alternatif ne devrait plus exister avec cet impl plus rapide. Donc, fondamentalement, je vois aussi que cela a un effet néfaste sur l'écosystème (bibliothèque) existant. IMO, un écosystème plus faible de bibliothèques JSON est un net négatif pour .NET (pas quelque chose que la plupart des consommateurs verront, ils utiliseront simplement les valeurs par défaut et oublieront les autres options), mais ce n'est pas ma principale préoccupation.

@davidfowl @shahid-pk

Malgré cela, j'aurais préféré que cela existait il y a 8 ans, car la principale raison du développement de ServiceStack.Text était que les sérialiseurs JSON .NET Framework étaient extrêmement lents. Mais après tout ce temps SS.Text a été étendue avec un certain nombre de fonctionnalités à travers toutes nos bibliothèques, personnalisations par exemple pour soutenir différents supports ServiceStack langues , différentes options de personnalisation JSON dans ServiceStack , support JSON dans ServiceStack Modèles , complexe soutien blob type JSON dans ServiceStack .Redis etc.

Alors maintenant, je me concentre sur l'évaluation de l'impact, à quoi ressembleront les nouvelles options d'API et de plugabilité, pouvons-nous y adapter les fonctionnalités existantes, serons-nous en mesure d'adopter comme sérialiseur JSON dans les applications SS .NET Core (qu'est-ce que ça va casser), est-ce que ServiceStack.Text pourra prendre en charge la nouvelle API, sera-t-il capable de prendre en charge .NET v4.5, sera-t-il capable de le personnaliser pour prendre en charge les formats filaires des déploiements existants, etc. fondamentalement, je n'ai aucune idée de l'impact sur tout cela ou de ce que la stratégie va évoluer car je n'ai pas encore eu l'occasion d'utiliser ou de voir quoi que ce soit. J'aurai plus de réponses quand j'aurai l'occasion de l'utiliser et j'aimerais évidemment avoir l'opportunité de tester l'intégration, de donner mon avis et de proposer des changements avant que les API ne soient gelées.

@mythz

Y a-t-il une raison pour laquelle la deuxième bibliothèque JSON la plus populaire après JSON.NET - ServiceStack.Text qui a déjà été remaniée pour être construite sur les API Span a été exclue ?

L'omission n'était pas intentionnelle. Nous avons activement recherché et travaillé avec les auteurs de bibliothèques JSON dans le cadre du référentiel CoreFxLab et l'un de nos développeurs a commencé à comparer nos travaux aux leurs. Je pense que la liste a été initialement remplie en utilisant des termes de recherche de base tels que "json" sur NuGet . Il semble que votre bibliothèque ne s'est tout simplement pas affichée. Je comprends que cela puisse être frustrant ou préoccupant pour vous, mais essayez de comprendre la situation de notre côté : on ne peut pas s'attendre à ce que notre équipe connaisse toutes les bibliothèques sous le soleil. Cette annonce fait partie de notre modèle de développement ouvert pour engager l'ensemble de la communauté. La seule raison pour laquelle nous avons tendance à nous adresser d'abord à des groupes plus petits est de nous assurer que nos plans et nos messages ont un niveau raisonnable de réflexion et de qualité avant de les partager avec le monde. Rien n'est encore définitif. Nous recherchons activement des commentaires supplémentaires.

Je suis curieux de savoir à quel « écosystème » vous faites référence et avec lequel vous espérez « travailler ensemble » ici ?

L'écosystème .NET et en particulier les parties intéressées par le traitement JSON.

Je serais évidemment intéressé par la compatibilité de ces API "enfichables" ou si cela finit par être un autre domaine où l'adoption et l'intégration de nouvelles bibliothèques MS finissent par tuer l'écosystème qu'elles remplacent.

L'objectif des points d'extension ASP.NET Core prévus est de permettre aux clients de remplacer le composant JSON intégré par la bibliothèque JSON de leur choix. Bien sûr, ASP.NET a toujours été livré avec "batteries incluses", c'est-à-dire une expérience par défaut raisonnable. Dans le passé, il s'agissait de Json.NET et, à l'avenir, il s'agit d'un composant fourni par la plate-forme. Étant donné que Json.NET était quelque peu câblé dans ASP.NET, le nouveau plan semble mieux net pour les gens comme vous ; donc je ne suis pas tout à fait sûr quelle partie de notre plan vous pensez être une menace.

Il y a une question ouverte sur ce que les modèles pour ASP.NET en 3.0 utiliseront.

N'est-il pas temps que les Templates soient modulaires ? Comme take vue.js par exemple.

La création d'une nouvelle application vue vous permet de choisir les choses que vous voulez. Pourquoi quelque chose de similaire ne peut-il pas être fait pour asp.net au lieu de créer 500 modèles pour répondre à tous les scénarios.

Voici un exemple concret d'une fonctionnalité de .ASP NET Core 2.2 où les formateurs d'entrée/sortie JSON non JSON.NET seront confrontés à des problèmes et comment une solution découplée peut aider :
La fonctionnalité ProblemDetails , qui permet une réponse d'erreur compatible 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);

Le code ci-dessus est annoté avec des attributs spécifiques JSON.NET, y compris un attribut de secours spécifique [JsonExtensionData] , toutes les propriétés JSON inconnues sont désérialisées dans ce dictionnaire et le contenu de ce dictionnaire est sérialisé dans la structure JSON normale.

Tout autre formateur d'entrée/sortie JSON doit désormais gérer ces attributs spécifiques à JSON.NET pour pouvoir sérialiser/désérialiser correctement ce type ou trouver un autre moyen, c'est-à-dire un retour à JSON.NET pour ces types.

Maintenant, si nous avons une spécification bien définie de fonctionnalités qu'un Input/OutputFormatter pour JSON doit prendre en charge pour 3.0, le problème ci-dessus n'existe pas car ces attributs pourraient résider dans un package Microsoft.Extension... et chaque Custom JSON Formatter pourrait les utiliser pour implémenter cette fonctionnalité pour être compatible.

À ma connaissance, il n'y a que quelques instances de code source "officiel" dans ASP.NET Core qui sont annotées par des attributs JSON.NET, mais j'ai également vu des bibliothèques tierces utilisant des attributs spécifiques JSON.NET (généralement pour spécifier le nom de l'attribut via [JsonProperty("name")]

FWIW, c'est de quoi parle https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Je pense que vous avez répondu avant de lire mon commentaire précédent qui IMO clarifie davantage mes préoccupations.

Nous recherchons activement des commentaires supplémentaires.

Où? Existe-t-il une proposition/un document d'API, une API a-t-elle été créée, sous quel référentiel est-elle développée ?

Je pense que vous avez répondu avant de lire mon commentaire précédent qui IMO clarifie davantage mes préoccupations.

Je l'ai lu, mais il semble que vous vous opposiez à tout défaut, ce qui, comme l' @davidfowl , n'est pas pratique pour nous. Mon point était que notre plan est une amélioration de ce que nous avons actuellement, c'est-à-dire un câblage de facto vers Json.NET. D'où ma question.

Où? Existe-t-il une proposition/un document d'API, une API a-t-elle été créée, sous quel référentiel est-elle développée ?

Nous n'avons délibérément pas encore fait de codage/conception d'API dans .NET Core, car nous voulions publier cette annonce en premier. Nous ne voulions pas que les gens lisent les feuilles de thé sans fournir le contexte fourni par cette annonce. En d'autres termes, restez à l'écoute, nous publierons bientôt des API et du code.

@terrajobst Impression entière pour poster ça

1. La décision d'apporter des modifications est prise.

À l'avenir, nous prévoyons d'apporter quelques modifications à notre support JSON :

1. Une conception préliminaire est faite
   Nous avons besoin d'API JSON hautes performances.
   Supprimez la dépendance d'ASP.NET Core vers Json.NET.
   Fournissez un package d'intégration ASP.NET Core pour Json.NET.

Tout cela signifie que la direction est prise. Tout ce qui est demandé à « l'écosystème » est de trouver des points douloureux évidents que les EM ne pourraient pas expliquer de manière réaliste.

L'omission de ServiceStack et sa discussion en tant que bibliothèque .NET de classe secondaire sont risibles. Même moi, uniquement sur les bibliothèques fournies par MS, cela ne signifie pas que je ne connais pas les alternatives.

Je n'ai aucun problème avec la prise de décisions par MS, mais si cela était indiqué directement et non couvert par des "rétroactions de la communauté" sur des décisions déjà prises.

C'est mon impression

@terrajobst

Je l'ai lu mais il semble que vous vous opposez à tout défaut

Jamais suggéré cela, JSON.NET était déjà la valeur par défaut avant cela. J'ai expliqué plus en détail ci-dessus, mais pour réitérer, cela est bien placé pour prendre en charge la valeur par défaut et devenir la nouvelle norme de facto où .NET Core n'aura effectivement que 2 sérialiseurs JSON à l'avenir : cette nouvelle valeur par défaut hautes performances de facto et JSON. NET pour des fonctionnalités personnalisées. D'autres sérialiseurs JSON vont devenir des niches, par exemple des fonctionnalités uniques ajoutées pour prendre en charge différents scénarios.

Nous n'avons délibérément fait aucun codage/conception d'API .NET Core parce que nous voulions d'abord recevoir cette annonce.

Ok, donc il n'est pas possible pour un "étranger" de savoir à quel point la connectabilité, l'extensibilité ou l'interopérabilité
sera encore.

Nous ne voulions pas que les gens lisent les feuilles de thé sans fournir le contexte fourni par cette annonce. En d'autres termes, restez à l'écoute, nous publierons bientôt des API et du code.

Il a donc été développé en interne ? Combien de temps après sa sortie, les personnes extérieures devront-elles tester et proposer des modifications à la conception de l'API ? Ma principale préoccupation concernant ce à quoi ressembleront les API « enfichables » et « extensibles », allons-nous être en mesure de « prendre le contrôle » et d'avoir un contrôle total sur le format de fil des types de référence/valeur ? Qu'en est-il des Types, Enums, bools, autres intrinsèques intégrés, etc. ? Par exemple, par exemple, sera-t-il capable de configurer bool pour accepter d'autres valeurs JSON populaires telles que "yes", "on", "1".

D'autres questions:

• Cette implémentation peut-elle être utilisée de manière autonome (dans un package NuGet séparé) ?
• La partie "plugable" de l'API est-elle liée au Web Framework ou peut-elle être utilisée ailleurs (par exemple Xamarin/UWP)
• Prendra-t-il en charge .NET Standard 2.0 ou .NET v4.5 ?
• Sinon, les API pourront-elles prendre en charge .NET Standard 2.0 ou .NET v4.5 ?

@mythz
Ce n'est pas vraiment développé en interne (à ma connaissance), la partie Reader/Writer se fait dans corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) et plus précisément, il n'y a pas encore d'API de haut niveau pour cela dans corefxlab.

Personnellement, j'attendrais que les parties de l'API extensibles/enfichables soient .NET Standard (c'est-à-dire les attributs, etc.). La bibliothèque dans corefxlab est .NET Standard 1.1 pour le moment, mais j'imagine que cela changera en fonction des objectifs de performances de la bibliothèque, etc.

@mythz

Vous semblez impatient de prendre mes déclarations et de les mettre dans un contexte « le verre est à moitié vide ». Je comprends, vous êtes sceptique. Je suggère que nous nous épargne un tas de frappes et que nous discutions de propositions d'API concrètes plutôt que de les discuter dans l'abstrait. Je suis assez convaincu que notre plan fournira les points d'extension dont vous avez besoin.

@terrajobst N'essayant pas d'être sceptique, essayant de savoir quelles sont les capacités proposées de haut niveau qui, je suppose, ont déjà été décidées (ou sont-elles toutes encore à déterminer ?). Cette annonce est la première que la plupart d'entre nous en a entendu parler, j'étais donc après quelques éclaircissements sur la façon dont elle est censée être enfichable, extensible et réutilisable. System.Text.JsonLab est-il l'

Cela peut être une fonctionnalité intéressante pour les créateurs de bibliothèques, mais vous devez également considérer les développeurs d'entreprise utilisant 50 bibliothèques avec des arborescences de dépendances et essayant de trouver des compatibilités entre celles-ci. Y aura-t-il des configurations de mappage de type redirection de liaison pour essayer de gérer les incompatibilités ?

Cette conversation semble à fleur de peau, que ce soit parce que les gens ont été offensés d'une manière ou d'une autre ou parce qu'ils essaient de défendre une action qui a été prise ou non prise. C'est difficile à lire. Excuses autour! S'il vous plaît, laissez l'état actuel et passez à autre chose.

Il semble qu'il y ait deux raisons à ce changement. Le premier est le désir d'améliorer les performances en utilisant de nouveaux types au sein de .Net Core.

De plus, il a été reconnu qu'il y a quelque temps, une erreur architecturale avait été commise en incluant des références matérielles à JSON.Net, une bibliothèque qui réside à l'extérieur de .Net. Pour résoudre ce problème, l'introduction d'une nouvelle implémentation JSON intégrée doit être effectuée avec des interfaces permettant aux tiers d'utiliser leurs propres implémentations.

Cela va-t-il casser les choses ? Oui! C'est pourquoi l'annonce porte une étiquette "changements de rupture". (Peut-être que cette étiquette devrait être reproduite ici.) Et comme il s'agit d'un changement décisif, une discussion a été lancée pour en explorer l'impact. De plus, pour minimiser l'impact, une bibliothèque supplémentaire permettant aux utilisateurs de continuer à utiliser JSON.Net sera fournie.

En tant qu'auteur de bibliothèque, cela m'intéresse vraiment et je préférerais que la conversation avance.

@Tornhoof en réponse à vos exemples, si je souhaite continuer à utiliser JSON.Net, je devrai également référencer la bibliothèque de compatibilité que j'ai mentionnée plus tôt. Il devrait être principalement plug-and-play, mais il peut y avoir des changements. Je ne veux certainement

La solution fournie par .Net devrait être plus générique que cela. La gestion de la sérialisation du modèle spécifique doit être effectuée par l'implémentation JSON choisie.

@mythz D'après tout ce que je sais et ce que j'ai vu des personnes impliquées dans cette proposition, vous aurez une longue chance d'examiner et de commenter l'API et la mise en œuvre proposées avant qu'elle ne soit publiée comme stable. L'un des objectifs de cette publication à un stade aussi précoce était de trouver des personnes comme vous précisément pour cette raison.

@gregsdennis
Je ne sais pas ce que vous entendez par plus générique?
En supposant que votre sérialiseur a le concept de remplacer les noms de propriété json, en modifiant leur comportement nul et/ou leurs implémentations de secours/attrape-tout et en supposant que les trois fonctionnalités font partie de la spécification partagée des sérialiseurs JSON pour .net core 3.0, puis le package d'implémentation mappe ces attributs aux détails de votre implémentation interne.
Par exemple, si votre bibliothèque préfère que vous utilisiez [DataMember] pour spécifier le nom des propriétés (comme le fait SpanJson), votre package d'intégration devrait le mapper facilement.
Je ne dis pas que les attributs sont la bonne façon, il se trouve qu'il s'agit simplement d'une partie visible de l'exemple de code.

De toute évidence, le monde idéal serait qu'aucune bibliothèque de framework ASP.NET Core n'utilise d'annotations spécifiques pour contrôler le comportement de sérialisation, mais en ce qui concerne cette fonctionnalité ci-dessus, c'est assez compliqué voire impossible, car la RFC exige le respect de certaines règles de nommage. .

Quoi qu'il en soit, je pense qu'il y aura de nombreuses discussions sur ces fonctionnalités partagées, comment les utiliser et les décrire à l'avenir.

Avez-vous l'intention d'utiliser les instructions SIMD dans le nouvel analyseur JSON, comme dans RapidJSON ?

Référence : http://rapidjson.org/

La suggestion proposée semble bonne, mais veuillez simplement essayer de lisser les " modifications de rupture ". ).

Ainsi, aucune de mes applications UWP n'a pu être construite en mode de publication pendant des mois, car j'ai dû réécrire tout le code qui utilisait la réflexion dans des bibliothèques tierces. Je sais que de nombreux auteurs de bibliothèques ont dû diviser à nouveau leurs implémentations pour exclure la réflexion dans ces parties UWP. La plupart des auteurs de bibliothèque ne sont pas venus à la fête et j'ai été obligé de quitter le navire. Bien que MS soit venu au premier plan et s'est engagé à mettre en œuvre une alternative dans la norme .net 2.1. nous savons que la réalité sur le terrain est que la norme .net 2.1 mettra des mois à se concrétiser à partir du changement de rupture initial.

Le fait est simplement que c'était un processus extrêmement perturbateur pour moi qui a eu des conséquences énormes pour les utilisateurs finaux et était tout sauf « fluide » et sans friction.

C'est certainement la bonne étape à faire.
Je me demande depuis un moment de voir cette référence Json.Net.

@Tornhoof Je pense qu'il doit y avoir une séparation définie : les interfaces que chaque fournisseur devrait implémenter pour être utilisé avec .Net Core 3.0, et l'implémentation par défaut qui est intégrée.

Les interfaces doivent être aussi générales que possible. Peut-être aussi simpliste que de définir uniquement les méthodes Serialize() et Deserialize() .

Les autres détails doivent être laissés à la mise en œuvre. Si l'implémentation par défaut utilisait un attribut pour définir un mécanisme de clé de propriété personnalisé, cela me convient. Je pense que c'est un détail spécifique à l'implémentation qui ne devrait pas faire partie de l'interface.

Cela dit, avoir la possibilité de personnaliser les propriétés des clés pourrait être une exigence, bien que je ne sache pas comment cela pourrait être codifié.

@gregsdennis Oui, vous avez raison, je regardais principalement le IInput/OutputFormatter, qui existe déjà actuellement dans ASP.NET Core et en particulier les problèmes liés à leur remplacement par des versions non JSON.NET.
Quoi qu'il en soit, comme le montrent vos commentaires et ceux de @mythz , je suppose que la définition de la portée deviendra intéressante et probablement pas aussi simple (je me souviens des problèmes avec les spécifications de l'interface DI). Il est donc préférable d'impliquer de nombreux points de vue différents dès le début du processus.

@Tornhoof a accepté. Les interfaces de formateur actuelles sont distinctement basées sur JSON.Net, mais pas tellement sur le sérialiseur lui-même, mais plutôt sur l'objet options. Il semble que nous aurions également besoin d'un moyen générique de communiquer les options (un objet d'options commun).

Cela implique-t-il que l'objet options dicte un ensemble de fonctionnalités minimum pour une implémentation ? Je ne pense pas. J'ai récemment implémenté un formateur pour mon sérialiseur qui ignore complètement l'objet options, mais c'était pour mon usage privé. Si je voulais en faire un pour un usage public, j'essayerais d'interpréter autant de ces options que possible afin de les prendre en charge.

Ce n'est pas comme ça que nous faisons les choses maintenant. Les options sont spécifiques au sérialiseur et il n'y a pas d'interface commune pour elles. Les formateurs dans MVC sont déjà correctement factorisés et ne sont couplés à rien. JsonResult aura des modifications importantes car il prend directement JsonSerializationOptions (le type JSON.NET).

J'allais dire la même chose. Nous ne prévoyons pas de construire une abstraction pour un lecteur/enregistreur/sérialiseur JSON. Ce n'est pas nécessaire ; les frameworks traitent des primitives d'E/S (telles que Stream , TextReader ) ou se connectent à un traitement de framework de niveau supérieur (tels que les formateurs ASP.NET Core).

En parlant de points douloureux : Personnellement (et je suis probablement dans une très petite minorité), je suis préoccupé par la nature laxiste de nombreux analyseurs JSON. Il existe une norme (tm) mais la plupart des parseurs ont choisi d'être indulgents et d'accepter les documents non conformes. Ce qui est mauvais à long terme, c'est que les développeurs n'implémentent pas vers une norme qu'ils implémentent vers une bibliothèque. Si la bibliothèque autorise les documents non conformes, les développeurs sont satisfaits tant que tous les bits utilisent la même bibliothèque. La douleur survient lorsque vous essayez de communiquer entre des domaines qui utilisent différentes bibliothèques. Soudain, il y a un problème car différentes bibliothèques prennent en charge différentes versions de JSON.

Devrions-nous supprimer les points douloureux en rendant la bibliothèque JSON aussi indulgente que possible (mais se termine peut-être par la complexité et l'ambiguïté) ou en attaquant la cause première ; bibliothèques JSON non-confirmantes.

Comme MS influent, il y a peut-être trop à demander à MS pour défendre avec succès les analyseurs syntaxiques JSON conformes afin d'améliorer l'interopérabilité à long terme, mais j'aimerais que ce soit différent. Peut-être être indulgent en lecture mais strict en écriture ?

(Choses qui ne sont pas dans la norme ; commentaires, virgules de fin, chaînes de guillemets simples, aucune chaîne de guillemets, etc.)

À mon humble avis, étant donné que JSON provient du monde des navigateurs Web, il semble que pour l'interopérabilité, nous devrions choisir le double comme représentation sous-jacente des nombres dans JSON, même si la norme JSON ne dit rien sur le représentant.

En parlant de l'API, je suppose implicitement que l'API la plus couramment utilisée sera une API de type DOM, mais je le trouverais également très utile s'il y avait une API de niveau inférieur qui me permettait de consommer le flux de jetons ou d'être signalé sur une interface visiteur pour ces gros documents dont je veux juste extraire une petite partie des données.

@mrange - Autant j'aime rendre les choses aussi strictes que possible... cela dépend de la possibilité d'apporter des modifications au code non conforme.

Si vous interagissez avec un service hérité sous le contrôle d'une autre entreprise, la possibilité de modifier le code incriminé est proche de zéro. Même l'écriture stricte, bien que plus faisable, n'est pas sans poser ses propres problèmes ici : et si le code incriminé s'attend à recevoir un objet non conforme qui lui est envoyé ?

@terrajobst merci ! Func<Stream, CancellationToken, Task<T>> et Func<T, CancellationToken, Stream, Task> est tout ce qui est nécessaire ici. Avec peut-être quelques surcharges pour TextReader/Writer, Span et string.

L'inconvénient est cependant lorsque vous souhaitez sérialiser / désérialiser le type d'une autre bibliothèque et que ce type est décoré avec des attributs d'un sérialiseur json que vous n'utilisez pas.

@thefringeninja si vous utilisez déjà la bibliothèque tierce pour les objets, vous avez déjà une référence à l'autre sérialiseur. Rien n'a changé là-bas.

Je ne suis pas du genre à semer la peur, mais je pense que

@terrajobst En ce qui concerne l'écosystème, bien qu'il soit impossible de rendre compte de toutes les bibliothèques, je ne pense pas qu'une recherche rapide de "json" sur NuGet en dirait beaucoup à qui que ce soit. Peut-être que le nom ServiceStack.Text n'est pas la façon la plus directe de dire "Hé! Je suis un package qui peut (dé)sérialiser JSON!", mais il y a eu des références au fil des ans pour le comparer. C'est peut-être un cas de dogfooding des valeurs par défaut de MS et soit de ne pas connaître l'étendue et la popularité des alternatives, soit de les utiliser assez fréquemment en interne pour se familiariser avec elles.

Je suis d'accord qu'il devrait y avoir une valeur par défaut pour fournir une expérience qui _fonctionne_ immédiatement. Si d'autres auteurs de bibliothèques de l'écosystème publient un package d'intégration, ce serait formidable s'ils pouvaient obtenir un plug-in dans les documents, les notes de version, etc. pour souligner qu'il existe des alternatives au-delà des valeurs par défaut. Le rendre difficile à découvrir serait problématique pour l'écosystème.

J'espère que si l'objectif de suppression de la dépendance est sincère, les API devraient mieux représenter les besoins de la communauté et ne pas être modelées directement sur Json.NET. L'essentiel est que cela nécessitera le travail de tous les auteurs de la bibliothèque, pas seulement de ServiceStack, mais les API ne devraient pas ressembler directement à l'API de Json.NET, sinon vous revenez à ce qui ressemble à une dépendance mais sans la dll.

les API ne doivent pas ressembler directement à l'API de Json.NET

... ou la mise en œuvre de tout autre fournisseur spécifique.

Une partie de la discussion qui a eu lieu avant l'annonce incluait l'idée que l'équipe .Net s'inspirerait de diverses bibliothèques pour avoir une idée de la façon dont divers problèmes ont été résolus, puis d'utiliser ce qu'ils considéraient comme le mieux adapté à ceux-ci. idées combinées avec les leurs. À bien des égards, ce n'est pas différent de la façon dont toute autre nouvelle bibliothèque JSON serait développée ; il se trouve que celui-ci sera inclus dans le cadre.

Nous sommes convaincus d'avoir une bibliothèque JSON hautes performances que nous n'avons pas à construire nous-mêmes. :)

Avant de discuter de quoi que ce soit, envisagez de tirer parti des résultats de Microsoft Research dans ce domaine (plus précisément, l'analyse sans branchement ni analyse FSM) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -Analyse des données/

Nous allons dans cette direction pour l'analyse JSON haute performance --- en plus de Span<T> bien sûr ---
cc @terrajobst @karelz

:( toute cette discussion sur JSON me fait sentir que ma question sur les modèles a mal tourné.

J'aurais aimé avoir plus de temps pour cette discussion parce que ça a été un enfer mais je vois pourquoi c'est devenu ce qu'il est. 4.6.1 doit rester cohérent avec les mises à niveau et les mises à niveau et les changements de rupture seront pour le reste.

J'ai vu beaucoup de packages rappelés pour core et 461 et j'espère que ce type ou ce changement résoudra le problème.

Je crains que le problème en cascade ne nous hante, veuillez nous prouver le contraire.

//dot net devs partout

@c0shea

[…] ce serait formidable s'ils pouvaient obtenir un plug-in dans la documentation, les notes de version, etc. pour souligner qu'il existe des alternatives au-delà des valeurs par défaut.

Je suis sûr que ce sera le cas. Les documents répertorient déjà des implémentations alternatives pour plusieurs sujets, tels que les conteneurs DI , les fournisseurs de journalisation , l' intégration Swagger ou les fournisseurs de bases de données EF Core .

@phillip-haydon
Le système de modèles prend déjà en charge les modèles personnalisables, et les modèles existants ont en fait déjà un certain nombre d'options. Il suffit de vérifier par exemple dotnet new mvc --help pour ce qui est actuellement possible. Je suis sûr que vous pourriez facilement étendre cela avec, par exemple, des intégrations alternatives de sérialiseur JSON, et les demandes de fonctionnalités ou les demandes d'extraction pour cela seront probablement acceptées sur aspnet/Templates .

@mrange - Autant j'aime rendre les choses aussi strictes que possible... cela dépend de la possibilité d'apporter des modifications au code non conforme.

Si vous interagissez avec un service hérité sous le contrôle d'une autre entreprise, la possibilité de modifier le code incriminé est proche de zéro. Même l'écriture stricte, bien que plus faisable, n'est pas sans poser ses propres problèmes ici : et si le code incriminé s'attend à recevoir un objet non conforme qui lui est envoyé ?

Peut-être avoir un mode strict par défaut et pouvoir le basculer explicitement vers un mode plus clément

@poke Je suppose que vous devez vraiment essayer vue cli, puis réessayer dotnew new. Le nouveau dotnet actuel... est... c'est...

Puis-je vous demander de vous rappeler que l'analyse de JSON par les différents navigateurs ne prend pas correctement en charge les valeurs int64 et nous donne la possibilité de sérialiser/désérialiser les longs sous forme de chaînes ? C'est une de ces choses que vous ne remarquez pas jusqu'à ce qu'il vous morde fort. Une variante de ceci est de pouvoir décider si les nombres sont désérialisés en entiers ou en longs par défaut.

Puis-je vous demander de vous rappeler que l'analyse de JSON par les différents navigateurs ne prend pas correctement en charge les valeurs int64 et nous donne la possibilité de sérialiser/désérialiser les longs sous forme de chaînes ? C'est une de ces choses que vous ne remarquez pas jusqu'à ce qu'il vous morde fort. Une variante de ceci est de pouvoir décider si les nombres sont désérialisés en entiers ou en longs par défaut.

....Ah, EcmaScript, merci d'avoir tout doublé. Je suis sûr que cela n'a pas causé de problèmes dans une autre partie du code...

En tant que puriste, je n'aime pas ce genre de choses.
En tant que réaliste, je pense que je vais devoir être d'accord avec cela.

Une partie de la nouvelle implémentation JSON sera-t-elle en .Net Standard 2.1 ?

J'ai un peu suivi ça et je ne sais pas si je l'ai raté. Existe-t-il une surface ou une interface API proposée que je peux examiner ? Je suis intéressé à voir la surface d'API pour cette proposition.

Existe-t-il une surface ou une interface API proposée que je peux examiner ?

Il y a encore beaucoup à faire, mais https://github.com/dotnet/corefx/pull/33216 est un début. Voici les notes de révision de

MISE À JOUR : Feuille de route également disponible ici .

alors, comment les fonctionnalités complètes de l'API aspnet 3.0 seront-elles comparées à l'API json.net ? De plus, json.net sera-t-il à toutes fins utiles supprimé par le développement de nouvelles applications avec des API natives ?

simplement améliorer les performances ou remplacer toutes les fonctions de json.net ?

C'est une nouvelle incroyable.

Je recommande fortement d'essayer de collaborer avec @neuecc son travail avec MessagePack , Utf8Json , ZeroFormatter etc a été phénoménal.

@linkanyway le résultat serait de remplacer un sous-ensemble de json.net, tout en fournissant de nouvelles API sans allocation.

Je soupçonne que la majorité des utilisateurs d'aspnet n'auraient pas de forte dépendance à l'implémentation de json.net et seraient capables de migrer de manière presque transparente.

Existe-t-il une surface ou une interface API proposée que je peux examiner ?

Il y a encore beaucoup à faire, mais dotnet/corefx#33216 est un début. Voici les notes de révision de

MISE À JOUR : Feuille de route également disponible ici .

@khellang Allons-nous obtenir de l'aide

Encore un bon mouvement en direction de l'OSS. Motiver les développeurs d'autres plates-formes commerciales à développer quelque chose de mieux que MS ne le fait déjà gratuitement, ou devenir pleinement OSS s'ils se soucient vraiment de la communauté.

Allons-nous obtenir de l'aide linguistique pour pouvoir écrire json en c# pour de vrai ?

@dotnetchris Je ne sais pas ce que vous entendez par "lang help" ? Littéraux JSON ? Je doute que cela se produise. Avez-vous regardé la prochaine fonctionnalité « langage intégré » ? Spécifiquement pour JSON ?

@khellang c'est certainement un pas dans la bonne direction, mais je veux dire un soutien complet. En utilisant les mêmes exemples d'objets de votre lien, plus proche de :

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

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

Avec suffisamment de vaudou, comme la génération d'objets implicites tuple/valuetuple/record pour que tout fonctionne au niveau de la langue dans les coulisses.

Inversement, le compilateur pourrait invoquer les services json, créer une classe puis travailler avec une instance de la classe comme si vous écriviez :

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

Edit: LOL @ downvoters.

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

@dotnetchris Si vous êtes intéressé, veuillez voter sur https://github.com/dotnet/roslyn/pull/24110. Il a été fermé par l'équipe IDE en raison d'un manque d'intérêt. Mais s'il y a suffisamment de voix, cela pourrait peut-être changer.

Les API JSON « intégrées » et « fournies par la plate-forme » signifient-elles qu'il ne s'agira pas d'un package nuget distinct (netstandard) ? Si ce n'est pas le cas, pourquoi pas ?

Je suppose que le nouveau framework partagé ASP.NET Core ne peut pas dépendre des paquets nuget, ou le peut-il?

N'y a-t-il pas déjà un espace de noms

Le supprimer casserait la rétrocompatibilité. Le quitter et démarrer une nouvelle API peut prêter à confusion. L'étendre/l'améliorer sans supprimer aucune API peut être un peu restrictif lors de l'ajout de nouvelles API.

Ce serait formidable d'avoir des interfaces pour JsonReader/JsonWriter, car il existe d'autres sources et cibles que les flux. Par exemple, j'utilise également JSON.NET pour MongoDB. C'est plus rapide et je n'ai pas à maintenir plusieurs sérialiseurs dans mes applications.

Je sais que cela pourrait nuire un peu à la performance, mais c'est très utile.

@SebastianStehle : JsonReader/JsonWriter sont des abstractions de haut niveau, voir le commentaire de terrajobst

Le plan pour 3.0 est le suivant :

1. API JSON hautes performances intégrées. Lecteur/enregistreur de bas niveau, un lecteur/enregistreur basé sur le flux et un >sérialiseur.
2. ASP.NET Core est enfichable par rapport au composant JSON.

Il y a une question ouverte sur ce que les modèles pour ASP.NET en 3.0 utiliseront. En fonction de la fidélité que nous pouvons fournir par 3.0, nous pourrions les faire intégrer le package d'intégration Json.NET. Cependant, l'objectif est de fournir suffisamment de fidélité et de parité pour ne dépendre que de celles intégrées par défaut.

L'API de haut niveau et facile à utiliser serait enroulée autour des flux pour désérialiser facilement depuis et vers les flux (c'est souvent le plus courant, lors de la sérialisation. Si vous voulez les meilleures performances dans les scénarios où vous ne pouvez pas utiliser les flux, vous devez utiliser le faible API de niveau qui fonctionnent sur Span<T> ou Memory<T> , en particulier lorsque vous avez déjà les données en main/en mémoire, vous souhaitez les utiliser et ne pas avoir la surcharge d'async.

@TsengSR

https://github.com/neuecc/Utf8Json ne fournit pas la fonctionnalité pour écrire des lecteurs/écrivains personnalisés pour des raisons de performances (appels virtuels et allocations je suppose) et j'ai pensé qu'ils aimeraient suivre le même chemin. Mais jusqu'à présent, je n'ai pas encore vu de code de sérialisation.

Je suis d'accord avec @JonasZ95 et @gregsdennis , j'espère que l'implémentation ne sera pas une simple abstraction des mêmes détails d'implémentation JSON.Net mais se concentrera plutôt sur ce à quoi elle _devrait_ ressembler.

Je pense aussi qu'il devrait être abordé comme 2 fonctions distinctes...

1. sérialisation / désérialisation
2. version json de ladite sérialisation et désérialisation.

Espérons que le framework ASP.NET Core utilisera une abstraction de sérialisation générique au lieu d'une abstraction spécifique JSON.

En ce qui concerne l'extensibilité, j'espère que le framework utilisera la technique DI de codage en abstractions (interfaces et non classes abstraites) et fournira simplement une valeur par défaut locale. Du point de vue des auteurs de bibliothèque JSON, cela fournirait la plus grande extensibilité car tout ce que vous auriez à faire est de fournir une classe d'adaptateur ASP.NET Core qui utilise l'implémentation de bibliothèque des interfaces, puis de configurer ASP.NET Core pour utiliser l'adaptateur de bibliothèque.

L'implémentation d'une bibliothèque tierce pourrait ressembler à ceci :
```C#
// référence des bibliothèques tierces
en utilisant Newtonsoft.Json ;

// exemple très naïf pour la brièveté juste pour
// faire le point
classe publique NewtonsoftAdapter : ISerializer
{
privé JsonSerializerSettings _settings;
privé Formatage _format;

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

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

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

}

...

// configuration de l'adaptateur avec des options de personnalisation tierces
var settings = nouveau JsonSerializerSettings
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
} ;
var adapter = new NewtonsoftAdapter(settings, Formatting.Indented);

// configuration du noyau asp.net
// où l'adaptateur implémente ISerializer (ou le nom que vous avez choisi)
// Les auteurs de bibliothèques pourraient même fournir leur propre méthode d'extension UseXYZ().
app.UseSerializer (adaptateur);
```

Il y a eu beaucoup de progrès dans l'analyse de texte basée sur SIMD, y compris pour le texte structuré, comme JSON . Y a-t-il une chance que le travail dans .NET Core approche ce niveau de performance ? Existe-t-il un moyen d'utiliser ces techniques ?

Hé, même Microsoft Research a de nouvelles solutions très performantes !

@AnthonyMastrean Merci d'avoir soulevé cette question. Je suis également intéressé par tous les points de repère pour avoir une idée de la façon dont cette impl Json actuelle se compare à simdjson.

Soit dit en passant, les auteurs de simdjson ont déclaré qu'ils travaillaient toujours à la publication complète de ce projet (je pense, plus de doc). Pour l'instant, vous pouvez lire des discussions intéressantes sur ce projet sur HN .

Existe-t-il un moyen d'utiliser ces techniques ?

Il se trouve que .NET Core 3.0 contient un tas d' intrinsèques dépendant de la forme , donc c'est tout à fait faisable 😄

Pour ce que ça vaut, je pense que dans une étendue Web, le réseau est un goulot d'étranglement principal, et bien qu'il soit cool de pouvoir analyser des gigaoctets en quelques secondes, je ne pense pas que ce soit très utile pour un projet Web.

Ne vous méprenez pas, des optimisations de performances comme celles-ci sont super cool et profiteraient probablement même à de très petits documents JSON. Mais pour l'instant, je pense que l'objectif de la nouvelle bibliothèque est d'éviter l'allocation de mémoire et de tout déplacer très étroitement vers la couche réseau. Cela seul devrait déjà améliorer considérablement les performances par rapport à JSON.NET. Mais lorsque le travail initial est terminé, envisager des optimisations supplémentaires peut être une autre histoire.

Là où je travaille, nous analysons tous les jours des téraoctets de JSON. J'en connais également d'autres qui utilisent .NET et F# pour traiter également de nombreux documents JSON. JSON est devenu plus qu'un simple serveur => mécanisme de transport du navigateur. Il est beaucoup utilisé dans les scénarios backend purs.

OFC ; il serait préférable que le backend passe à un format binaire comme AVRO/Protobuf, mais c'est souvent difficile et JSON présente certains avantages (je l'admets à contrecœur). Avoir un analyseur JSON très rapide pourrait littéralement économiser 10 000 $ par mois pour des entreprises comme la nôtre.

@poke Ce projet relève de .NET Core (pas d'ASP.NET...), il est donc pertinent pour toutes les charges de travail, pas seulement pour le Web.

Je peux être d'accord sur l'idée qu'il est trop tard pour travailler sur cette technique d'optimisation spécifique pour .NET Core 3.0, mais j'espère qu'une enquête est faite maintenant pour s'assurer que l'optimisation sera possible à l'avenir (c'est-à-dire sans casser les changements ).

Peut-être mieux faire quelque chose comme un assemblage de mappage unifié ('System.Text.Json.Mapping') où définir des attributs et d'autres éléments pour mapper JSON aux classes C# ? Après avoir implémenté cette chose, tous les analyseurs/écrivains JSON existants peuvent être adoptés pour utiliser le mappage unifié. Il permettra à toutes les applications .NET Standard de migrer entre différentes bibliothèques JSON sans aucune difficulté

@AlexeiScherbakov Les nouvelles abstractions n'aident pas vraiment. Vous vous limiterez à nouveau en choisissant une abstraction commune et il y aura toujours de nouvelles bibliothèques qui ne peuvent pas utiliser l'abstraction et qui en nécessitent plus. Il en a toujours été ainsi, par exemple avec la journalisation .

Je ne pense pas que la création d'une nouvelle abstraction basée sur cette nouvelle implémentation nous apportera un quelconque avantage, en particulier lorsque la bibliothèque est conçue pour être de toute façon beaucoup moins riche en fonctionnalités.

Et il existe en fait déjà une abstraction netstandard existante sous la forme de DataContract/DataMember que j'espère que cette bibliothèque finira par respecter (même si cette abstraction est quelque peu limitée).

À part un attribut ignore, nous ne pouvons pas avoir un milliard de nouveaux attributs et scénarios à prendre en compte. Préférez un mappage 1:1 de JSON aux classes, si vous voulez faire quelque chose hors de la norme ou prendre en charge l'héritage, utilisez json.net.

Personnellement, je ne me soucie pas tellement des classes JSON <=> C#. Je pense qu'il est important d'avoir le concept d'analyse/écriture JSON séparé du modèle objet C# créé du modèle JSON.
De cette façon, je (qui ne se soucie pas tellement des classes JSON <=> C#) peut avoir un analyseur très efficace sans aller-retour sur un modèle d'objet aimable.

@mrange c'est à servent le lecteur et l'écrivain

Cela signifie-t-il que je peux m'attendre à une API de lecture/écriture dans l'API JSON fournie par la plate-forme ? Le pattern Lecteur/Ecrivain est-il le plus efficace ?

Il existe 3 types de System.Text.Json à ce jour :

• Utf8JsonReader - un moyen rapide, non mis en cache et en avant uniquement de lire du texte JSON encodé en UTF-8.
• Utf8JsonWriter - ^ identique à Utf8JsonReader , mais pour l'écriture.
• JsonDocument - un modèle de document à accès aléatoire en lecture seule pour les charges utiles JSON.

Tous les types ci-dessus devraient être (plus ou moins) sans allocation 👍

Nous avons posté le papier simdjson : https://arxiv.org/abs/1902.08318

Des travaux sont également en cours sur un port C# de simdjson : https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

Peut-être mieux faire quelque chose comme un assemblage de mappage unifié ('System.Text.Json.Mapping') où définir des attributs et d'autres éléments pour mapper JSON aux classes C# ? Après avoir implémenté cette chose, tous les analyseurs/écrivains JSON existants peuvent être adoptés pour utiliser le mappage unifié. Il permettra à toutes les applications .NET Standard de migrer entre différentes bibliothèques JSON sans aucune difficulté

J'espère vraiment que la nouvelle abstraction ne repose pas sur des attributs. J'essaie d'utiliser des objets POCO propres dans les bibliothèques sous-jacentes et d'utiliser DI pour leur éviter d'avoir à connaître l'implémentation. Je ne veux certainement pas décorer mes classes sous-jacentes avec les attributs requis pour l'implémentation. Cela pourrait entraîner la création de classes supplémentaires dans les couches d'interface utilisateur qui ne font essentiellement que mapper un objet de domaine existant à json.

Le mappage 1-1 des classes json aux classes c# serait probablement une meilleure approche, au moins dans certains cas, vous pourriez éviter de créer de nouvelles classes même si les classes de type viewmodel seront toujours nécessaires dans d'autres cas.

Ce serait bien s'il y avait une sorte de moyen d'ignorer les propriétés qui ne sont pas nécessaires et à tout le moins de contrôler certains des aspects de la sérialisation (comme le chameau contre le boîtier pascal).

@mrange c'est à servent le lecteur et l'écrivain

@davidfowl Cela signifie-t-il que les nouvelles API

Le support de la sérialisation débarque au moment où nous parlons . Le problème connexe dit :

• En raison de contraintes de temps et pour recueillir des commentaires, l'ensemble de fonctionnalités est destiné à un produit minimum viable pour la version 3.0.
• Des scénarios d'objets POCO simples sont ciblés. Ceux-ci sont généralement utilisés pour les scénarios DTO.
• L'API conçue pour être extensible pour de nouvelles fonctionnalités dans les versions ultérieures et par la communauté.
• Attributs au moment de la conception pour définir les différentes options, mais prennent toujours en charge les modifications au moment de l'exécution.
• Hautes performances utilisant IL Emit avec retour à la réflexion standard pour la compatibilité.

Il détaille également comment ils prévoient de prendre en charge la conversion enum, la gestion des valeurs nulles, camel- vs PascalCasing, etc.

Si vous avez des commentaires à ce sujet, vous devez laisser vos commentaires dans ce numéro ou dans la pull request.

@lemire Wow, c'est vraiment cool. simdjson est en effet super rapide.

Avez-vous la possibilité d'implémenter le benchmark de sérialisation JSON de TechEmpower ? (je sais que ce sera beaucoup plus de travail)

J'ai trouvé ces implémentations : Dans le référentiel TechEmpower et dans le référentiel ASP.NET .

@KPixel C'est de la sérialisation, non ? Pendant ce temps, simdjson est un analyseur syntaxique... À moins que je ne sois confus au sujet des termes, ces choses vont dans des directions opposées?

Ma faute. J'ai supposé qu'il y avait une partie désérialisation (qui utiliserait l'analyseur syntaxique).

Le System.Text.Json sera-t-il un paquet nuget standard .net ? ou C'est quelque chose qui n'est disponible que pour .net core 3.0 ?

@John0King regarde ici : https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Je pense que la convivialité devrait également être au centre du nouveau package JSON. Une fonctionnalité que je pense qu'il devrait avoir est la prise en charge de la validation de schéma JSON. Newtonsoft facture cela. C'est quelque chose de suffisamment fondamental pour qu'il soit fourni gratuitement dans la plateforme, comme ce fut le cas pour la validation de schéma XML.

@ jemiller0 Mon impression est que la validation XML a été quelque peu mitigée et que le schéma JSON a eu une adoption moyenne dans le vrai mot. Vous pouvez toujours faire vérifier le schéma via une bibliothèque en tant qu'étape supplémentaire... Bien sûr, cela peut impliquer l'acquisition d'une licence logicielle, mais est-ce un gros problème ?

@lemire Oui, c'est une grosse affaire, si vous développez un logiciel open source et que vous souhaitez rendre votre logiciel accessible à tous. L'analyse XML n'est pas un sac mélangé. Ça marche. Même chose avec la validation de schéma JSON. Le fait de ne pas disposer d'un moyen gratuit intégré de le faire rend la plate-forme .NET non compétitive.

Je n'ai jamais vu de schéma json utilisé dans le monde réel. Même ainsi, cela ne devrait

@jemiller0

Je suis vraiment curieux : est-ce que d'autres langages de programmation offrent un support de schéma JSON dans leur bibliothèque standard ?

L'objectif de cette bibliothèque est d'être une bibliothèque de bas niveau hautement performante pour fonctionner avec JSON. Tout ce qui n'est pas cela, qui inclut la plupart des fonctionnalités les plus avancées de JSON.NET ainsi que les schémas JSON, n'en fera pas partie.

Si vous souhaitez une validation de schéma JSON, vous êtes libre d'implémenter un validateur au-dessus de cette bibliothèque, qui doit être suffisamment bas pour vous permettre de le faire.

Je ne pense pas que la validation du schéma JSON dans une bibliothèque standard ait quelque chose à voir avec le fait qu'une plate-forme soit compétitive ou non.

L'objectif de cette bibliothèque est d'être une bibliothèque de bas niveau hautement performante pour fonctionner avec JSON. Tout ce qui n'est pas cela, qui inclut la plupart des fonctionnalités les plus avancées de JSON.NET, n'en fera pas partie.

Sauf qu'il inclura également des fonctionnalités de niveau supérieur, conçues pour être un remplacement immédiat de Newtonsoft.Json 😊

@poke Vous avez le droit d'avoir l'opinion que vous voulez avoir, tout comme moi. XML est utilisé partout. Par conséquent, à juste titre, Microsoft a inclus la prise en charge de la validation avec le .NET Framework. Désormais, JSON fait fureur et est utilisé PARTOUT, dans les fichiers de configuration, les API Web, etc., etc. Il est logique d'avoir le même niveau de prise en charge de JSON que celui historiquement pris en charge pour XML. Personnellement, je trouve un peu ridicule que Microsoft utilise des logiciels tiers pour commencer. Cela devrait être une caractéristique essentielle de la plate-forme.

@lemire Je vais bientôt vérifier Python. À ce stade, je découvrirai qu'il est intégré ou inclus en tant que package facilement installable. Je serais très surpris si ce n'était pas le cas. Je cherche à utiliser NJsonSchema pour ce dont j'ai besoin en ce moment. Dès le début, vous pouvez voir que la documentation est nulle. Oui, s'appuyer sur des bibliothèques tierces qui peuvent être de qualité ou non est une excellente idée pour des choses comme travailler avec JSON qui est totalement omniprésent et utilisé partout. Comptons tous soit sur des logiciels commerciaux, soit sur des packages tiers sans documentation. .NET ne doit pas seulement correspondre à d'autres plates-formes comme Python. Ils devraient les battre en fournissant un logiciel de qualité avec une documentation appropriée prête à l'emploi. Cela a été historiquement la façon dont cela a fonctionné. Là où je travaille, tout le monde déteste .NET et veut me forcer à utiliser Python. Je ne sais pas si vous l'avez remarqué, mais de plus en plus de gens abandonnent le navire et passent à Python. Dire à mon patron que je dois acheter une licence pour faire quelque chose de simple comme valider JSON ne fonctionnera pas. Ce que j'obtiendrai en retour est demandé pourquoi je voudrais utiliser .NET en premier lieu. Peu importe le fait qu'il s'agisse d'un projet open source pour lequel vous ne pouvez pas obtenir de licence de toute façon. J'espère que je trouverai que NJsonSchema fonctionne. Je signale simplement une omission flagrante dans le cadre qui devrait être évidente pour quiconque travaille avec JSON.

J'utilise des schémas JSON au travail et je préfère avoir un vrai bon analyseur JSON qu'un demi-bon analyseur JSON + un validateur de schéma JSON. Aussi AFAIK JSON Schema est un _draft_ 7 en ce moment. Donc, avoir un schéma JSON en tant que bibliothèque externe qui peut évoluer rapidement avec le schéma est logique pour moi. Avoir JSON Schema dans la feuille de route serait bien cependant.

@jemiller0

Il est logique d'avoir le même niveau de prise en charge pour JSON que celui historiquement pris en charge pour XML.

.Net inclut également la prise en charge de XSLT et XPath. Si vous voulez "le même niveau de support", cela ne signifie-t-il pas que vous auriez également besoin d'une version de ceux-ci pour JSON ?

Ce que j'essaie de dire, c'est que l'écosystème JSON est différent de l'écosystème XML. Les deux ont des modèles d'utilisation différents et les technologies associées ont des numéros d'utilisation et des niveaux de normalisation différents. De plus, XML a été ajouté à .Net avant que NuGet, git ou GitHub n'existent. De nos jours, il est beaucoup plus facile et beaucoup plus acceptable de s'appuyer sur une bibliothèque tierce.

Donc, non, je ne pense pas qu'il soit logique de dire aveuglément "XML avait ça, donc JSON doit l'avoir aussi".

De plus, la validation est simplement orthogonale à l'analyse. Je serais tout à fait d'accord avec l'ajout d'un support de validation à un moment donné (éventuellement dans un autre package). Mais ce n'est pas du tout nécessaire pour un bon support d'analyse.

Nous avons besoin d'un moyen de validation stricte des données dans les requêtes API REST.
Parce que nous sauvegardons le json qui passe par l'API sans erreur et plus tard, nous ne pouvons pas l'analyser dans JS à cause des virgules de fin, etc.

Et pourquoi ne pouvez-vous pas valider cette demande maintenant ?

@phillip-haydon @freerider7777 Je pense que tout analyseur JSON décent devrait respecter la spécification JSON et lancer des erreurs (et/ou des avertissements) lorsque le document n'est pas bien formé (par exemple, lorsqu'il a des virgules à la fin). C'est assez basique mais aussi distinct de la validation qui est la comparaison des données JSON avec un schéma (du moins, c'est comme ça que j'utilise les termes).

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

Microsoft, l'une des plus grandes sociétés de développement de logiciels, n'a personne pour travailler sur la validation. Un analyseur rapide est plus important. Il vous permettra d'analyser le JSON invalide à la vitesse de la lumière. :-) Personne n'a pensé qu'une validation rapide pourrait être utile. Tout comme ASP.NET Core, une mise à niveau rapide et simplifiée vers les formulaires Web.

Et pourquoi ne pouvez-vous pas valider cette demande maintenant ?
@phillip-haydon Dans le code du contrôleur avec un tel json :
ModelState.IsValid == vrai

🤦‍♂️

Vous pouvez déjà faire une validation basée sur votre schéma json avec 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>

Je suis d'accord avec @lemire , il y a une différence entre valider la structure de JSON et valider le JSON par rapport à un schéma. Je n'ai aucun doute que Microsoft a consacré du temps et des efforts pour implémenter correctement le premier... ce dernier est un cas de coin et je ne pense pas qu'il s'intègre dans la conception générale de cette bibliothèque JSON. Je suis presque sûr qu'ils ont clairement indiqué que cette bibliothèque JSON est conçue UNIQUEMENT pour fournir une analyse rapide, efficace et nécessaire au fonctionnement du noyau asp.net. Il n'a pas été conçu pour inclure les _extras_ fournis avec l'analyseur syntaxique de newtonsoft. (reportez-vous au commentaire de

Je ne pense pas que le fait qu'ils n'aient pas intentionnellement conçu cela pour qu'il soit livré avec toutes les cloches et tous les sifflets en fait un produit de qualité inférieure.

Cela s'est-il produit avec l'aperçu 4 ?

Existe-t-il des plans pour faire le System.Text.Json.Serialization.Policies.JsonValueConverterclass public pour permettre le remplacement des classes de convertisseur de Json.net ?

System.Text.Json livré avec un support .Net complet via nuget ? Ce serait certainement bien d'assurer une interopérabilité complète et de tirer parti des avantages du cadre complet.

System.Text.Json été récemment modifié pour produire des binaires netstandard2.0 pour l'expédition OOB ; https://github.com/dotnet/corefx/pull/37129 :

Si possible, vous devez cibler .NET Core 3.0 et obtenir les API System.Text.Json intégrées. Cependant, si vous devez prendre en charge netstandard2.0 (par exemple, si vous êtes un développeur de bibliothèque), vous pouvez utiliser notre package NuGet qui est compatible netstandard2.0.

bénéficie du cadre complet

Qu'est-ce que c'est encore ? ??

@khellang

Ma préférence serait un nuget avec plusieurs saveurs, y compris un framework complet (4.5 ou tout autre minimum acceptable), standard et core. Il est préférable d'utiliser des assemblages en boîte.

Le problème lié ci-dessus fait référence à ce package, mais il n'est pas pris en charge :

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

Existe-t-il un package actuellement pris en charge ?

Ma préférence serait un nuget avec plusieurs saveurs, y compris un framework complet (4.5 ou tout autre minimum acceptable), standard et core.

Pourquoi préféreriez-vous cela? S'il n'y a pas besoin de multi-cibler, c'est à dire que toutes les API utilisées font partie du standard, il vaut mieux n'avoir qu'une seule cible 😊

Existe-t-il un package actuellement pris en charge ?

Je ne pense pas qu'il soit encore expédié. Le PR a été fusionné il y a quelques jours. Ce paquet était un projet communautaire qui a maintenant été transféré à MS.

@khellang cela dépend des détails -- je faisais une déclaration générale.

Si la version net standard devait omettre quelque chose de la version net core qui serait possible avec la version nette complète, je préférerais que les trois saveurs soient disponibles. Même raisonnement général, je suppose, que la déclaration originale du problème lié ci-dessus concernant la préférence des utilisateurs pour cibler la version dans la boîte.

Lors de l'ajout d'une référence au package nuget, la saveur la plus compatible appropriée serait automatiquement sélectionnée. Donc, ce n'est pas grave. Si la bibliothèque consommatrice est standard net, alors la saveur standard net serait sélectionnée.

Ma préférence générale pour les saveurs in box est que lorsque je goto definition , je reçois des sources décompilées. Si je goto definition sur les bibliothèques standard du net, je ne vois généralement que les sources de stub qui lèvent des exceptions NotImplemented .

bénéficie du cadre complet

Qu'est-ce que c'est encore ? ??

De nombreuses applications utilisent .NET Framework non pas parce qu'elles veulent absolument rester en dehors de .NET Core, mais parce que .NET Core n'est pas une option. J'utilise .NET Core quand c'est une option ; lorsque je dois cibler des versions de Windows inférieures à Windows Server 2012 (la version minimale de .NET Core 3.0), je dois utiliser .NET Framework. Même si je suis sûr que c'était une décision très douloureuse d'abandonner la prise en charge de Windows Server 2008 R2 et versions antérieures, c'est une décision très douloureuse pour chaque entreprise avec des clients payants avec des serveurs qu'ils ne veulent pas mettre à niveau/souvent recréer à partir de zéro juste pour que nous puissions utiliser un outil légèrement plus récent.

Personne ne serait plus heureux que moi si je pouvais arrêter d'utiliser .NET Framework demain, mais même avec toutes les opportunités WPF et Windows Forms dans .NET Core 3.0 et au-delà, Microsoft rend cela pratiquement impossible avec ses stratégies de support. J'ai essayé d'en discuter avec tous ceux qui voudraient écouter chez Microsoft, mais malheureusement, je n'ai pas encore reçu le moindre e-mail accusant réception du message.

@JesperTreetop sans parler du manque de prise en charge LTS pour les versions de .NET Core qui valent la peine d'être utilisées pour une entreprise ;) J'espère que nous obtiendrons la prise en charge LTS sur 3.x -- en tant qu'architecte .NET de mon organisation, je ferai pression pour Adoption de .NET Core si nous obtenons une version 3.x avec prise en charge LTS.

@marksmeltzer Le billet de blog Introducing .NET 5 d'hier montre que .Net Core 3.1 sera LTS et devrait sortir en novembre 2019.

Ce nouveau sérialiseur JSON prendra-t-il en charge les types F# ?

@rliman eh bien actuellement, il ne prend pas en charge Guid ou Enum, il a donc un long chemin à parcourir. Je suis d'accord pour dire que la prise en charge complète des types d'options F # similaires à C # nullable devrait être requise IMHO

Personnellement, je pense que c'est une solution précipitée à une mauvaise décision de conception architecturale. Cela aurait dû être fait il y a longtemps... Maintenant, cela va causer beaucoup de douleur partout... Des développeurs de bibliothèques aux développeurs d'entreprise.

Il n'y a pas de moyen facile de "lisser" cette nouvelle "fonctionnalité".

C'est MS essayant de résoudre un problème qu'ils ont causé en premier lieu. Et maintenant, tout le monde doit en payer le prix.

Avec NET Core, il semble dès le départ que le wagon soit un peu trop "rapide"... Cette approche purement "agile" devra peut-être ralentir un peu et laisser tout le monde reprendre son souffle.

On dirait qu'avec ASP.NET Core, ces "fonctionnalités" (changements de rupture) sont devenues la nouvelle norme.

À mon avis, ASP.NET Core a désespérément besoin d'une refonte de son processus de conception architecturale. Parce que maintes et maintes fois, continuez à créer ces fonctionnalités « nous le corrigerons plus tard ».

Je développe avec ASP.NET Core depuis les premières versions bêta... Et c'est une grande amélioration sur .NET.

Mais l'équipe MS devrait s'arrêter un instant et réfléchir à la manière dont elle peut résoudre le vrai problème ici : des décisions de conception architecturale précipitées et incohérentes.

Revenez en arrière et lisez d'autres fils... Il semble que ce soit un thème récurrent.

Il est donc peut-être temps de s'asseoir et de repenser à la meilleure approche pour créer un produit plus stable.

Classic .NET n'est peut-être pas aussi puissant que Core... Mais il est très stable et cohérent depuis la 2.0.

Juste mon avis.

Salut @suncodefactory ,
je me souviens il y a quelque temps quand ppl a crié après ms pour ne pas utiliser les bibliothèques open source, maintenant ils sont blâmés pour le faire :D
De mon point de vue, les API Aspnet/core MVC sont très stables depuis mvc1/2 ! La raison pour laquelle aspnet était stable depuis 2.0 était qu'il n'a jamais changé/amélioré du tout 😄.
Pour être honnête, si vous utilisez une fonctionnalité avancée d'une bibliothèque de sérialisation, vous avez la possibilité d'y repenser et peut-être d'aborder le problème avec une structure de données adaptée à la tâche, au lieu de prétendre que tous les sérialiseurs prennent en charge toutes les fonctionnalités du langage, imo c'est le mauvais problème à résoudre et la mauvaise façon d'utiliser la sérialisation.
La clarté, la rétrocompatibilité et les futures extensions sont ce qui motive mes dtos sérialisables, des compromis très différents utilisés dans les objets de logique métier courants (ceux-ci sont privés, ont beaucoup de fonctions, etc.)

Nous avons pu déplacer les microservices du net framework vers Linux (net core) sans presque aucun effort de la part des équipes de produits. Je ne sais pas de quoi vous parlez. Microsoft fait un excellent travail en accélérant la mise en œuvre de changements comme celui-ci qui étaient attendus depuis longtemps.

Salut @suncodefactory ,
je me souviens il y a quelque temps quand ppl a crié après ms pour ne pas utiliser les bibliothèques open source, maintenant ils sont blâmés pour le faire :D

Pour moi, il ne s'agit pas de bibliothèques tierces... Il s'agit de la conception architecturale qui, dans ce cas particulier, fait défaut ou tout simplement fausse.

De plus, je n'ai jamais parlé d'asp.net classique... Je parlais de .NET Framework 2.0. Et la raison pour laquelle il était stable n'était pas parce qu'il n'y avait pas d'améliorations comme vous le prétendez faussement (puisque le noyau .net est basé sur .NET 4.6.1). La raison en était qu'il était bien planifié et architecturé.

Quant à la qualité du noyau aspnet par rapport au mvc asp.net classique, cela n'a rien à voir avec ce fil particulier.

Ce fil concerne un changement de rupture que MS est sur le point d'expédier une fois de plus sans y penser à fond.

Nous avons pu déplacer les microservices du net framework vers Linux (net core) sans presque aucun effort de la part des équipes de produits. Je ne sais pas de quoi vous parlez. Microsoft fait un excellent travail en accélérant la mise en œuvre de changements comme celui-ci qui étaient attendus depuis longtemps.

Des changements comme celui-ci ne devraient pas du tout se produire... Vous êtes donc satisfait des changements de rupture ?

Et dire que l'équipe principale d'asp.net a fait un excellent travail pour expédier les changements n'est tout simplement pas vrai.

Je développe avec asp.net core depuis la bêta 3 et je suis presque sûr que le processus de conception architecturale fait défaut.

Quant à la qualité du noyau asp.net par rapport au classique ... Je n'ai aucune objection car je pense également qu'il est meilleur que le classique.

Mais ce n'est pas parce que le noyau asp.net est meilleur que le classique qu'ils font un excellent travail de conception d'architecture. Ces deux sujets sont complètement différents.

Pouvons-nous limiter cette discussion à la fonctionnalité JSON dans .NET Core 3 s'il vous plaît ?

Des changements comme celui-ci ne devraient pas du tout se produire... Vous êtes donc satisfait des changements de rupture ?

Donc aucune amélioration ne doit être apportée ? Pourquoi êtes-vous même un programmeur si vous ne voulez pas que le logiciel évolue, grandisse et s'améliore ?

@suncodefactory

Des changements comme celui-ci ne devraient pas du tout se produire... Vous êtes donc satisfait des changements de rupture ?

Ah, allez, vous donnez l'impression que "rupture de changement" signifie que vous devez abandonner votre projet et recommencer à zéro.

Combien de changements décisifs pouvez-vous compter dans ASP.NET Core 2.x/3.0 qui nécessitaient plus de

• Référencer un autre package
• Utiliser un espace de noms différent
• Modification de plus de 5 lignes de code
• Suppression de 1 à 2 lignes de code (c'est-à-dire Propriétés des classes Options)

??

@suncodefactory

Ce fil concerne un changement de rupture que MS est sur le point d'expédier une fois de plus sans y penser à fond.

Comment est-ce réellement un changement _breaking_ ? Les nouvelles API JSON sont un tout nouvel ensemble d'API qui sont introduites dans .NET Core et qui ne suppriment ni ne cassent aucun élément existant. Oui, vous verrez des choses et des bibliothèques y basculer éventuellement car il offre différentes opportunités d'optimisation, mais vous n'êtes pas obligé de l'appliquer à votre code.

En parlant d'ASP.NET Core en particulier, bien que _« cela n'a rien à voir avec ce fil de discussion »_, vous avez le choix de continuer à utiliser Newtonsoft.Json si vous dépendez de certaines de ses fonctionnalités les plus avancées. Oui, vous devrez modifier du code pour que cela fonctionne, mais je ne considère pas cela vraiment comme une rupture étant donné que vous ne devez le faire que si vous souhaitez réellement passer à la nouvelle version. C'est la bonne chose maintenant : vous avez plus de choix.

Si vous n'aimez pas cela pour une raison quelconque, n'hésitez pas à vous en tenir au .NET Framework qui est un ensemble de fonctionnalités connu, stable et fixe. Cela restera là pendant un certain temps, vous pouvez donc totalement compter sur cela. Mais s'il vous plaît, arrêtez d'utiliser ce fil pour diffuser votre agenda anti-nouveauté quand _"cela n'a rien à voir avec ce fil en particulier"_.

Deux questions d'un utilisateur d'EF Core.

1. System.Text.Json prendra-t-il en charge les références circulaires ? Des références circulaires peuvent apparaître dans les données EF Core où il existe des liens de navigation allant dans les deux sens entre les classes. Json.NET gère cela avec des paramètres tels que
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. Avec la montée en puissance des classes de style DDD avec des setters privés et des constructeurs privés, peut-on System.Text.Json désérialiser ces types de classes ?

@JonPSmith IMO, cela ne devrait pas avoir d'importance. Vous ne devriez jamais sérialiser une entité directement. Vous devez sérialiser une projection. Cela évite les références circulaires et n'expose pas toutes les données, en particulier lorsque vous ajoutez plus de propriétés à l'entité qui peuvent finir par être sensibles.

@JonPSmith : À

1. Je n'ai jamais vu de meilleure pratique qui recommande de désérialiser directement les entités (sauf dans les exemples de tutoriel les plus simples). Les références circulaires ont toujours un coût. Cela nécessite un suivi des objets déjà traités, c'est-à-dire des allocations mémoire et des cycles CPU supplémentaires. Mais l'un des objectifs de messagerie de la nouvelle bibliothèque JSON est d'éviter exactement ces allocations de mémoire
2. Invalide également, car vous ne sérialisez jamais dans un modèle de domaine, surtout pas lorsque vous obtenez les données via une requête Web telle qu'un appel WebApi. Dans DDD, vous devez toujours travailler avec des événements/commandes, envoyer la commande à votre application Web, récupérer (et déshydrater) l'entité du référentiel (via le mappage ORM ou EventSourcing), appliquer la commande, la conserver.

En plus de cela, la nouvelle API JSON est destinée aux scénarios hautes performances. Pour tout le reste où vous avez besoin d'un ensemble de fonctionnalités riche, vous (et devriez) toujours utiliser JSON.NET ou tout ce qui répond à vos besoins.

@suncodefactory C'est le contraire d'un changement radical. À l'heure actuelle, dans ASP.NET Core 2.2, JSON.NET est utilisé par le framework ainsi que par le code utilisateur. Cela peut provoquer des conflits avec votre propre utilisation de Newtonsoft.Json ; si ASP.NET Core 3.0 est passé à JSON.NET 12.x et qu'il y avait une sorte de problème qui a cassé votre application, vous auriez un problème.

Par exemple, regardez Microsoft.Extensions.Configuration.Json 2.2.0 - il a une dépendance sur Newtonsoft.Json 11.0.2. C'est un package de configuration ; rien à voir avec la gestion des requêtes HTTP ou ASP.NET Core MVC. Ou regardez Microsoft.IdentityModel.Protocols.OpenIdConnect , qui l'utilise pour gérer les jetons Web JSON ; c'est un chemin chaud qui a besoin d'autant de performances que possible. JSON.NET n'est en aucun cas une bibliothèque lente, mais elle établit un équilibre entre les performances, la richesse des fonctionnalités et la prise en charge d'un large éventail de scénarios d'utilisateurs. La nouvelle bibliothèque JSON de Microsoft n'a pas besoin de le faire, car JSON.NET existe. Ainsi, il peut se concentrer sur la gestion des bases absolues avec des performances maximales.

.NET a toujours eu sa propre solution de sérialisation JSON dans System.Runtime.Serialization.Json , mais dans le monde hautes performances de .NET Core, ce n'est pas une très bonne solution. Je ne voudrais certainement pas qu'il soit invoqué pour vérifier les informations d'identification sur chaque demande entrante. Une nouvelle bibliothèque JSON, avec une gestion des données UTF-8 moderne et des allocations minimales, est la bienvenue.

Vous pourrez toujours référencer Newtonsoft.Json dans votre application et continuer à l'utiliser comme pipeline de désérialisation/sérialisation pour les données de demande/réponse comme auparavant. Et à partir de maintenant, vous pourrez le faire sans vous soucier de la version dont dépend le framework Core. C'est une victoire pour tout le monde.

Merci @phillip-haydon et @TsengSR pour vos réflexions. Je demandais si ces fonctionnalités seraient prises en charge et vous dites que ce n'est pas le cas, qui comprend et accepte. Je continuerai à utiliser Json.NET pour le cas où j'ai besoin de sérialiser/désérialiser les classes EF Core.

D'AILLEURS. J'ai une raison valable de sérialiser/désérialiser les classes d'entités EF Core de style DDD. J'ai une bibliothèque qui contient une fonctionnalité que j'appelle Seed from Production qui permet aux développeurs de prendre un instantané des données d'une base de données de production, d'anonymiser toutes les données privées, puis de créer une nouvelle base de données avec l'instantané.

J'avais besoin de cette fonctionnalité pour un de mes clients et au lieu d'écrire juste pour eux, je l'ai intégré dans ma bibliothèque open source EfCore.TestSupport afin que d'autres puissent l'utiliser (et mon client n'a pas eu à me payer pour cela).

Existe-t-il un plan pour soutenir [DataContract] , [DataMember] et vos amis ?

Aujourd'hui, c'est un moyen de définir comment les types doivent sérialiser/désérialiser (par exemple, le nom du champ) d'une manière qui n'apporte de dépendance à aucune bibliothèque de sérialisation au projet qui l'utilise.

Le JsonNamingPolicy actuel ne prend qu'une chaîne, il n'y a donc aucun moyen d'inspecter les attributs du membre.

Salut.
Nous venons d'essayer de basculer nos micro services vers DotNet core 3 preview 6 et nous sommes incapables de désérialiser nos types de référence immuables : classe avec des propriétés immuables (pas de setters) et un seul constructeur pour définir toutes les propriétés. Json.net gère correctement ces classes.
Est-ce un problème du besoin de l'API System.Text.Json ou est-ce un plan pour le prendre en charge ?
Merci pour vos réponses

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

Merci @khellang.
Un support est effectivement prévu mais pas pour la version 3.0.
Il semble possible de continuer à utiliser Json.net avec DotNet core 3 mais je ne sais pas comment le faire (ajouter une référence de package ne suffit pas). Y-a-t-il un moyen de faire ça?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

Merci pour votre aide les gars.
Ça marche !
J'ai raté le guide de migration où tout est expliqué :

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

IMO json.net est à moitié cuit et en faire la valeur par défaut (c'est-à-dire pour le signaleur) qui casse le code existant était prématuré.

D'un autre côté, la migration de .NET Core 2.2 vers 3.0 est une mise à niveau de version majeure et même si l'équipe .NET Core ne suit pas strictement le contrôle de version sémantique, je m'attendrais à ce que les choses se cassent lors de la mise à niveau d'une version à une autre sans modifications explicites (comme ajouter explicitement la bibliothèque de Newtonsoft dans le pipeline)

Fermeture étant donné qu'il s'agit d'une annonce et non d'un problème

Bien que la communauté ait beaucoup de voix contre l'amélioration, en tant que nouveau cadre hautes performances, la mauvaise vitesse est inacceptable.

Je sais que cela a déjà été dit, mais j'aimerais également ajouter mon souhait.

Ce serait vraiment génial si nous pouvions avoir des objets immuables. Je sais que c'est possible en ajoutant Json.NET au MVC-Pipeline mais dans mon cas, mes tests échouent tous car j'utilise ReadAsAsync<> qui est maintenant implémenté quelque part dans une dépendance de pair de Microsoft.AspNet.WebApi.Client et cela repose sur System.Text.Json

Nous fournissons la bibliothèque de classes standard .NET aux clients afin qu'ils puissent utiliser notre bibliothèque pour travailler sur n'importe quelle plate-forme prenant en charge la norme .NET. Nous devons utiliser System.Text.Json dans notre bibliothèque de classes. Quel sera le plan pour prendre en charge System.Text.Json dans .NET Standard ?

@alsami

Ce serait vraiment génial si nous pouvions avoir des objets immuables.

Avez-vous seulement besoin de la possibilité d'empêcher les autres de le faire muter ou avez-vous également besoin de la possibilité de créer de nouvelles instances avec des pièces remplacées intelligemment (comme les collections immuables et Roslyn) ? Si vous avez besoin du premier, nous avons ce qu'il vous faut avec les prochaines API DOM JsonDocument .

@mwoo-o

Quel sera le plan pour prendre en charge System.Text.Json dans .NET Standard ?

Il est disponible sous forme de package NuGet pour .NET Standard 2.0 : System.Text.Json .

@terrajobst

Merci. Quand ce System.Text.Json sera-t-il inclus dans le SDK standard .NET ?
La norme .NET 3.0 (ou d'autres versions ultérieures) inclura-t-elle le package System.Text.Json ? Cela se produira-t-il dans la version de production du SDK .NET Core 3.0 ?

@terrajobst

Est-il prévu de faire fonctionner la méthode Deserialize avec PipeReader ? Ou ajoutez la méthode Patch qui peut être utilisée dans des scénarios de streaming où nous n'avons pas toutes les données lorsque nous commençons la désérialisation.

Voici une version simplifiée de l'API proposée :

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

capacité à empêcher les autres de le faire muter

Seulement cela actuellement. Est vraiment juste pour les « objets de transfert de données ». Bonne nouvelle!

@mwoo-o

Merci. Quand ce System.Text.Json sera-t-il inclus dans le SDK standard .NET ?
La norme .NET 3.0 (ou d'autres versions ultérieures) inclura-t-elle le package System.Text.Json ? Cela se produira-t-il dans la version de production du SDK .NET Core 3.0 ?

Il n'y a pas de SDK standard .NET. .NET Standard est une surface API, disponible sur toutes les plateformes prises en charge. Vous pouvez envoyer System.Text.Json dans n'importe quelle application qui exécute des cibles sur les plates-formes prises en charge par la norme .NET, voir Prise en charge de l'implémentation .NET .

@TsengSR

Il n'y a pas de SDK standard .NET. .NET Standard est une surface API, disponible sur toutes les plateformes prises en charge.

Eh bien, il existe un type de projet qui vous permet d'utiliser les API. Je pense que @mwoo-o demande si nous prévoyons d'ajouter System.Text.Json à .NET Standard. La réponse est non. Bon, maintenant nous prévoyons de laisser ce package NuGet.

C'est terrible. Trop peu de fonctions à appliquer dans le projet.