Json.NET VS JsonSubTypes

This bug and many others related to time: https://github.com/JamesNK/Newtonsoft.Json/issues/862 And they will never get fixes, because the project is kind of dead. Edit: and actually, the creator claim to have made it like this on purpose, so I don't trust it anymore.

There's a related discussion on the GitHub repo:

Nuget is where you'll get 3rd party libraries (such as Newtonsoft.Json for JSON processing)

Common convention (with rare exceptions) is to name your project the same as your assembly name and default namespace. For example, Newtonsoft.Json.csproj makes an assembly called Newtonsoft.Json.dll with the default namespace of Newtonsoft.Json. Inside that project directory (which usually also has the same name), subdirectories would match namespaces nested inside the default, like in that example there is a folder named Serialization which contains classes that are all in the namespace Newtonsoft.Json.Serialization. Classes in this nested namespace can automatically access classes defined in parent namespaces without extra using statements, like how JsonProperty.cs can reference JsonConverter from the Newtonsoft.Json namespace, but it needs a using statement at the top of the file in order to access classes from the sibling namespace Newtonsoft.Json.Utilities

As I said, I'm not familiar with C# but on a quick Google it seems there isn't one idiomatic way to handle JSON in C# - instead a multitude of different libraries/packages for doing so. This seems... ...irritating. json.NET (https://www.newtonsoft.com/json) seems to be one of the best (but again, I don't know C#).

MonoGame abstracts a lot of the rendering work and is easy to use for 2D games (I haven't tested its 3D support so far). It also provides you with a content pipeline plus audio and input handlers. All that's left for you to do is roll your own Entity Component System, physics, and game logic. If you're not interested in writing your own physics, there are libraries out there already. Additionally, if you don't want to get caught up in the details of data serialization, Json.NET is a great package for serializing data in JSON format. That makes it perfect when paired with a map editor such as Tiled, which can export to JSON.

Also file an issue report with Newtonsoft because IMO that should not be happening.

If messages are arriving as Json you can use JsonSubTypes to deserialize to different DTOs based on the UUIDs (https://github.com/manuc66/JsonSubTypes) and then use the visitor pattern to dispatch the DTOs to the correct method.

Personally I've had good success with JsonSubTypes for deserializing discriminated unions from JSON. It'll serialize stuff into the right type, and then you just need a switch statement to typecast it afterwards.

There is a small use case that I consider valid for this. It would be for determining a set of pre-defined behaviors to make available to definitions of entities in a game. And the json data would not be coming from external sources, it would be tightly controlled by me as the developer. The response you made to the other comment on my post shared a link that said the practice shouldn't be done with untrusted data, and there would be no untrusted data since there'd be no external data. The article also mentions to restrict the types that can be deserialized, and that is definitely possible. The architecture pattern for this is ECS (Entity Component System) and the data-drive portion might have been a mis-naming of my post, it's more of a lot of the design of entities and components is stored in data files, and there are a few cases where I will want to associate certain functionality in the code with these data entity definitions. No operating system level functionality would be exposed. I've even been referred to a library available via nuget that will allow for what I'm attempting to do: https://github.com/manuc66/JsonSubTypes