6 ms·
To me, it's pretty much unbelievable that Microsoft introduces an agent framework while for JSON serializing third-party Newtonsoft is still the go-to. Edit. I
by kurokawad 11mo ago
To me, it's pretty much unbelievable that Microsoft introduces an agent framework while for JSON serializing third-party Newtonsoft is still the go-to.
Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!
- vintermann 11mo agoWhat's wrong with System.Text.Json?
- anonymars 11mo agoLast I checked they stubbornly insisted on reinventing the wheel and ignoring everything in System.Runtime.Serialization so you had to redecorate everything with their new attributes. For example https://github.com/dotnet/runtime/issues/29975 https://github.com/dotnet/runtime/issues/29975. So we stuck with Newtonsoft for the time being.
- WorldMaker 11mo agoThere is a 3rd Party library for that now: https://github.com/zcsizmadia/ZCS.DataContractResolver https://github.com/zcsizmadia/ZCS.DataContractResolver I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rather than the rule. You could even keep DataContract/DataMember during the transition and just take an additive approach for JsonIgnore. [0]: It was a good idea, in theory, but so annoying in practice.
- anonymars 11mo agoFor me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember) It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem Case in point: https://github.com/dotnet/efcore/pull/28084/files https://github.com/dotnet/efcore/pull/28084/files
- WorldMaker 11mo ago> but you have to pull in the library anyway That library is also out-of-the-box in the BCL in .NET > 5, though. It's not an extra install (except for projects stuck in .NET 4.x). I get the desire to avoid that sort of redundancy in the BCL itself, but also explicit is better than implicit, which was the baseline theory for why System.Runtime.Serialization was the way it was even as it added more and more implicit "conventions", and if System.Text.Json supported the SRS attributes out-of-the-box there would be just as many complaints about "implicit magic" or it not following WCF conventions hard enough and that making it harder to migrate things using SRS attributes when you wanted different behavior in JSON serialization than you would want in WCF SOAP serialization. SRS has too much WCF baggage, unfortunately for all of us. Perhaps what's left of the disagreement here between us is if System.Text.Json counts as "first-class framework attributes" and it certainly seems that way to me in .NET 5+, and especially as we celebrate the release of .NET 10. It's a small redundancy in the BCL, but it's still just "as BCL" and "first-class".
- Deukhoofd 11mo agoIs it? We've switched over to System.Text.Json entirely.
- monerofglory 11mo agoThe go-to nowadays is System.Text.Json, developed by the same person as Newtonsoft.Json, built in to .NET. Newtonsoft.Json as the primary JSON serializer (at least in every place I've worked) has NOT been the case versus System.Text.Json for years. Though it certainly used to be the case.
- kurokawad 11mo agoUh okay! I was not aware of this. Thanks for pointing that out. Why is there so much difference in the NuGet downloads between both libraries tho?
- Hawxy 11mo ago> Why is there so much difference in the NuGet downloads between both libraries tho? Because there's a boatload of older .NET apps that have been using Newtonsoft for over a decade already and aren't in a rush to switch. Anything built on .NET Framework is likely to still use Newtonsoft.
- akoeplinger 11mo agoSystem.Text.Json ships as part of the shared framework in recent versions of .NET so for most users it won't be restored from nuget.org
- xnorswap 11mo agoSystem.Text.Json isn't needed as a nuget library for newer development, the library is only needed for older stuff. Those older stuff are likely running newtonsoft.Json anyway. There's also a load of .NET Framework applications still running Newstonsoft.
- WorldMaker 11mo agoSystem.Text.Json is out-of-the-box in .NET > 5. The NuGet package is primarily a compatibility layer for people still supporting .NET 4.x for whatever reason.
- gf000 11mo agoDoesn't Text.Json have a much narrower scope and plenty of features supported by Newtonsoft not available?
- BatteryMountain 11mo agoHaven't touched the newtonsoft package since .net core 3 / or about 5 years go? Something like that. Its not really getting updates and its huge/slow compare to built in one. The built in one is much better these days and plays well with other subsystems in aspnet.
- pier25 11mo agoThere's so much stuff they could be working on instead like a first party Postgres driver, better OpenAPI, improving Minimal APIs, etc.