Newtonsoft.Json

g some Microsoft projects. The cherry on that cake was author's response indicating that he doesn't even understand why this design is problematic in the first place: "I like what it does, I have no plans to change it, and I would do it again if given the chance." I wouldn't trust any parser written with this kind of attitude.

/github.com/BcryptNet/bcrypt.net) Logging: - Microsoft has their own basics for this, but there are also a lot of 3rd party solutions, you can see a maintained list here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/lo... (I personally use Serilog). Serialization/Deserialization: - Microsoft have just added their own internal JSON serializer to .NET Core, so you should probably use that where you can, but it doesn't have anywhere near the same features that Newtonsoft's Json.NET does, so if you're in need of those then that's still the battle-tested standard (https://github.com/JamesNK/Newtonsoft.Json). Time: - Personally I've never had a reason to use it over the standard DateTime, but I've heard good things about NodaTime (https://github.com/nodatime/nodatime) Images: - System.Drawing still exists in the standard library for Core, but it's Windows only I believe - ImageSharp is a great library for native image stuff in .NET Core, works across all platforms (https://docs.sixlabors.com/index.html). There was some hullaballoo a little while back about it's license, but that appears to be resolved now as it's Apache 2. - There's also an ImageMagick library if that's your jam (https://github.com/dlemstra/Magick.NET) Networking: - .NET obviously has it's own httpclient, but it's worth mentioning Polly here (https://github.com/App-vNext/Polly). It allows you to extend the default Http Client with short circuits, automatic retries, exponential backoffs, etc. Databases: - Probably doesn't need saying, but Entity Framework for an all in one migration, entity mapping and database access library (https://github.com/dotnet/efcore). Since moving to Core, it's also a lot faster now, although I think it's still lacking a couple of features from the old framework version. - Dapper is focussed on being fast and simple (https://github.com/StackExchange/Dapper) - NHibernate is also still a really powerful database library, even if I think it's API kinda sucks (https://github.com/nhibernate/fluent-nhibernate)

er cases when implementations try to be "smart" to transparently compensate for JSON lacking something (e.g. https://github.com/JamesNK/Newtonsoft.Json/issues/862). Conversely, if you are writing in a language that has integral support for XML - say, XQuery, or even VB.NET (https://docs.microsoft.com/en-us/dotnet/visual-basic/program...), the complexity is mostly not there. At the very least, if you control the format - which you have to, if you're in a position to decide what to use - then you can certainly stick to the subset of XML that is not anymore complex than JSON.

.. except it can reformat it, and even helpfully adjust it from one timezone to another. Semantically it's the same date, of course, but it's not at all the same string, and sometimes that matters a lot. So this is the worst case because it's just silent data corruption. For some mysterious reason, the author believes that this is acceptable default behavior - i.e. "it's a feature, not a bug". It's especially ironic to look at all the mentions in GitHub ticket, as various projects that rely on the library run into this issue (one of them is mine): https://github.com/JamesNK/Newtonsoft.Json/issues/862

y luxurious all dancing all singing JSON libraries intended for less restricted CLR platforms like Windows do all kinds of amazing tricks to reduce and optimize their use of reflection. Some of those have been stripped down and ported to Unity, but others haven't. JSON.Net is one of the most advanced feature-rich C# JSON libraries, and it is free, but it is not the fastest. The free version doesn't run on Unity out of the box, but there is a striped down simplified version that runs on Unity available on the Unity Asset Store for $25. JSON.NET home page: http://www.newtonsoft.com/json JSON.Net source code: https://github.com/JamesNK/Newtonsoft.Json Unity JSON.Net port: https://www.assetstore.unity3d.com/#!/content/11347 FastJSON is quite fast true to its name, free, has a lot of advanced features, is deeply customizable, is highly optimized and benchmarked against other libraries, and there's a great in-depth article comparing it to other libraries and explaining its optimization techniques. It hasn't been ported to Unity, but that might be worth doing, since it's such a nice piece of work. I asked the author about it, and he said that its speed was the result of dynamic code generation features that Unity doesn't support. That would sacrifice some of the optimizations and advanced features, but still might be worth doing. FastJSON article and benchmarks: http://www.codeproject.com/Articles/159450/fastJSON FastJSON source: https://github.com/mgholam/fastJSON Full Serializer is a well written free JSON library with lots of useful features that is specifically designed for Unity from the start, which avoids using anything that will limit optimization, like anything higher than .Net 2.0 subset features, advanced reflection features, LINQ, code generation and even exceptions. So far, it seems like the best balanced compromise I've found between Unity's limitations and a full set of useful features, and it looks to me like well written but not overly complex code. FullSerializer source: https://github.com/jacobdufault/fullserializer Thread asking about using FastJSON on Unity, where the FullSerializer author chimes in: https://www.reddit.com/r/Unity3D/comments/2a4c7p/using_fastj... JSONObject is another free simple JSON library written for Unity, which I've been using for years, and while it works for basic stuff, I'm not very happy with it (which is why I'm looking around for alternatives). It's not particularly efficient (in speed or runtime size), has a terrible API, few advanced features, and some embarrassing bugs. (It doesn't correctly handle string escapes like \r \n \u1234 etc -- c'mon, there's a very simple explicit JSON spec that defines every bit of the syntax: follow it!) JSONObject source: https://github.com/mtschoen/JSONObject JSONObject on the Asset Store: https://www.assetstore.unity3d.com/en/#!/content/710 Unity now has its own JSONUtility module that at first glance seems like it might be useful, but once you try to actually use it for anything in the real or virtual world, you hit a wall, because it's a wolf in sheep's clothing. Even worse than a wolf: it's layered directly on top of Unity's infamous serialization system, and inherits all its bizarre quirks and limitations, making it practically useless (and probably slow). https://docs.unity3d.com/ScriptReference/JsonUtility.html https://docs.unity3d.com/Manual/JSONSerialization.html First, in order to begin to understand how truly fucked up Unity's JSONUtility library truly is, you have to understand how truly fucked up Unity's serialization system is, and this great classic blog posting by Lucas Meijer bravely and honestly touches the surface, then falls off into the deep end: Serialization in Unity: https://blogs.unity3d.com/2014/06/24/serialization-in-unity/ While this reddit discussion goes to the heart of the matter: Unity Serialization is truly FUBAR: https://www.reddit.com/r/Unity3D/comments/2e9vlg/unity_seria... For many Unity developers, an important reason for using a JSON serialization library is to avoid using Unity's serialization system. So the idea of JSONUtility being layered on top of the system they were trying to get away from doesn't appeal to them. "This is why I am moving away from scriptable objects style services and into using static clr objects that load their configuration from csv / json txt files. I am loosing editor integration, but Im gaining peace of mind that unity wont blow up and corrupt my array of 100 items, levels, whatever." [–]nventimiglia Expert 2 points 2 years ago https://www.reddit.com/r/Unity3D/comments/2e9vlg/unity_seria... I'd prefer to build on top of Unity's built-in optimized JSON parser if that were possible, layering a system like Full Serialization on top of it without tangling with Unity Serialization, but the current JSONUtility API makes that impossible. Unity should publish the source for JSONUtility to the community (and throw in Serialization too please, so we can at least understand how it works when we're forced to interact with it), and accept pushes, please!

't seem to find it. Could it be unwillingness like you suggested? Seems unlikely to me as it does seem quite useful for some quick and dirty applications at the very least. Or maybe could it be that satisfactory implementations could not be made?