Почему библиотеки Microsoft зависят от Newtonsoft.Json?

Вероятно, это началось еще тогда, когда Microsoft создала библиотеку ASP.NET Web API, по крайней мере, тогда я ее запомнил, если не ошибаюсь. Как бы то ни было, с тех пор его HTTP-пакеты запускались в зависимости от библиотеки Newtonsoft.Json для сериализации (де) данных в и из JSON.

Почему такая крупная компания, как Microsoft, может добавить зависимость от библиотеки с открытым исходным кодом? Мне кажется странным, даже если они собирались использовать полностью открытый исходный код с .NET, потому что, насколько я знаю, это была единственная не-Microsoft библиотека, используемая в качестве зависимости.

В качестве дополнительного вопроса, получает ли Джеймс Ньютон-Кинг финансовую поддержку от Microsoft?

— paulius_l
источник

Похоже, у Microsoft есть мешки с деньгами, которые можно разбрасывать. Несмотря на то, что они достаточно богаты, их ресурсы не безграничны, что делает их расчеты такими же, как у вас: «почему я должен тратить время и деньги на то, чтобы написать что-то, для чего уже существует совершенно хорошая альтернатива с открытым исходным кодом?»

— Роберт Харви

Microsoft стала более дружелюбной по отношению к открытым источникам несколько лет назад; они включили jQuery в ASP.NET MVC на ранней стадии. Переход с открытым исходным кодом с .NET является частью этого сдвига.

— Роберт Харви

Вы можете узнать немного больше об истории JSON.NET здесь: newtonsoft.com/json/help/html/Introduction.htm

— Роберт Харви

Почему нет? Это библиотека JSON-сериализации мирового класса, я полагаю, MS мудро решила сосредоточить свои усилия на других проблемах, а не изобретать велосипед.

— Фергал Моран

Интересно, что Джеймс Ньютон-Кинг объявил в марте 2018 года, что он присоединится к Microsoft.

— Йерун

Самая прямая цитата, которую я нашел, является частью объявления Скотта Гатри о дорожной карте MVC 4 в 2012 году (по-видимому, в автономном режиме, но доступного через Wayback Machine ), которая содержит следующую цитату:

Json.NET : мы планируем использовать разработанный в сообществе стек сериализации Json.NET в нашем стандартном JSON-форматере в ASP.NET Web API. Json.NET обеспечивает гибкость и производительность, необходимые для современной веб-инфраструктуры.

Таким образом, простая причина в том, что это лучшая из доступных библиотек JSON, в то время как MVC был одним из первых крупных проектов Microsoft, которые отказались от укоренившегося подхода NIH , характерного для MS, а также других программных гигантов, и обратились к лучшим в своем классе проектам с открытым исходным кодом. в качестве основы для своих предложений.

— Авнер Шахар-Каштан
источник

Все честно, и, конечно, мы не хотим возвращаться в "NIH". Несмотря на это, я хотел бы, чтобы эта библиотека все еще была включена в стек MS. Причина в том, что для любых внешних библиотек существует огромное давление, чтобы они не имели внешних, неосновных зависимостей фреймворка. Это единственная библиотека, с которой часто приходится сталкиваться, когда это трудно сделать, и неудивительно, что это такая функциональная возможность, как думать о .NET без встроенных инструментов XML (XElement и т. Д.). Неудивительно, что это библиотека # 1 во всех nuget (!). Мои 2 цента.

— Николас Петерсен

@NicholasPetersen Вы можете прочитать здесь о предложении включить его в .NET Standard. В последний раз я проверял обсуждение, большинство было против, но, возможно, за включение подмножества, более легкого парсера JSON в стандартные библиотеки.

— Авнер Шахар-Каштан

Они дают хорошие результаты, хотя я и не думал, что его следует добавлять как часть .NET Standard, как некоторые упоминали, поскольку он кажется слишком тяжелым, чтобы навсегда зацементировать его в netstandard. Моя мысль включала это как часть netcore (я полагаю, в corefx), но я признаю, я мог бы быть наивным в том, что я запрашиваю здесь. Некоторые люди там предложили, чтобы это было частью NET Foundation, звучит хорошо, но я не знаю, облегчит ли это реальную проблему, позволяющую другим библиотекам не ссылаться на библиотеку, внешнюю по отношению к платформе.

— Николас Петерсен