Pourquoi les bibliothèques de Microsoft dépendent-elles de Newtonsoft.Json?

Cela avait probablement commencé il y a longtemps lorsque Microsoft a créé la bibliothèque d'API Web ASP.NET, du moins c'est à ce moment-là que je m'en souviens si je ne me trompe pas. Quoi qu'il en soit, depuis lors, ses packages HTTP ont commencé en fonction de la bibliothèque Newtonsoft.Json pour la (dé) sérialisation des données vers et depuis JSON.

Pourquoi une entreprise aussi grande que Microsoft ajouterait-elle une dépendance à une bibliothèque open source? Je trouve cela étrange même s'ils allaient devenir entièrement open source avec .NET à l'époque, car c'était la seule bibliothèque non Microsoft utilisée comme dépendance, pour autant que je sache.

En prime, James Newton-King obtient-il un soutien financier de Microsoft?

— paulius_l
source

Vous donnez l'impression que Microsoft a des sacs d'argent à dépenser. Bien qu'ils soient assez riches, leurs ressources ne sont pas illimitées, ce qui rend leur calcul identique au vôtre: "pourquoi devrais-je dépenser du temps et de l'argent pour écrire quelque chose pour lequel une excellente alternative open-source existe déjà?"

— Robert Harvey

Microsoft a commencé à devenir plus convivial depuis des années; ils ont intégré jQuery dans ASP.NET MVC dès le début. Aller en open source avec .NET fait partie de ce changement.

— Robert Harvey

Vous pouvez en savoir un peu plus sur l'histoire de JSON.NET ici: newtonsoft.com/json/help/html/Introduction.htm

— Robert Harvey

Pourquoi pas? C'est une bibliothèque de sérialisation JSON de classe mondiale, je suppose que MS a judicieusement décidé de concentrer ses énergies sur d'autres problèmes et de ne pas réinventer la roue.

— Fergal Moran

Fait intéressant, James Newton-King a annoncé en mars 2018 qu'il rejoindrait Microsoft.

— Jeroen

La citation la plus directe que j'ai trouvée fait partie de l'annonce par Scott Guthrie de la feuille de route MVC 4, en 2012 (apparemment hors ligne mais disponible via la Wayback Machine ) qui contient la citation suivante:

Json.NET : nous prévoyons d'utiliser la pile de sérialisation Json.NET développée par la communauté dans notre formateur JSON par défaut dans l'API Web ASP.NET. Json.NET offre la flexibilité et les performances requises pour une infrastructure Web moderne.

Donc, la raison simple est qu'il s'agit de la meilleure bibliothèque JSON disponible, tandis que MVC a été l'un des premiers grands projets de Microsoft à abandonner l' attitude enracinée des NIH qui caractérisait MS ainsi que d'autres géants des logiciels, et à atteindre les meilleurs projets open source comme fondements de ses propres offres.

— Avner Shahar-Kashtan
source

Très bien, et nous ne voulons certainement pas revenir à "NIH". Même ainsi, je souhaite que cette bibliothèque soit toujours incluse dans la pile de MS. La raison en est qu'il y a une énorme pression pour que les bibliothèques externes n'aient pas de dépendances de framework externes non-core. C'est la seule bibliothèque que l'on rencontre fréquemment où c'est une chose difficile à faire, et pas étonnant, c'est une telle fonctionnalité de pain et beurre, c'est comme penser à .NET sans outil XML natif (XElement etc.). Pas étonnant que ce soit la bibliothèque n ° 1 de tous les nuget (!). Mes 2 cents.

— Nicholas Petersen

@NicholasPetersen Vous pouvez lire ici une proposition pour l'inclure dans .NET Standard. La dernière fois que j'ai vérifié la discussion, la majorité y était opposée, mais peut-être pour avoir inclus un sous-ensemble, un analyseur JSON plus léger dans les bibliothèques standard.

— Avner Shahar-Kashtan

Ils font de bons arguments, même si je ne pensais pas qu'il devrait être ajouté dans le cadre de .NET Standard, comme certains l'ont mentionné, car il semble beaucoup trop lourd pour être cimenté dans la norme nette pour toujours. Ma pensée était de l'inclure dans le cadre de netcore (je suppose dans corefx), mais j'avoue que je pourrais être naïf dans ce que je demande ici. Certaines personnes là-bas ont suggéré que cela fasse partie de NET Foundation, ça sonne bien, mais je ne sais pas si cela résoudrait le problème réel de permettre aux autres bibliothèques de ne pas avoir à référencer une bibliothèque externe au framework.

— Nicholas Petersen