snapshooter
snapshooter copied to clipboard
SwissLife-OSS
System.Text.Json support
Currently, snapshooter is using Newtonsoft.Json (also called Json.Net) serializer to compare JSON files. Microsoft introduced its own JSON Serializer in the System.Text namespace, which is now recommended for simple use cases for .NET Core 3.1 and up. However, the feature set is still far from the very poweful Newtonsoft.Json as the migration steps explains. https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to
Especially, using MS serializer requires strictly formatted Json with "": non-string values for string properties are NOT allowed anymore. For instance, {"str1": 1, "str2": true} is ok for Newtonsoft when linked with an object having only string, but raise Exception with MS which required {"str1": "1", "str2": "true"}
I just migrated one project from Newtonsoft to Text.Json. For my unit tests using Snapshooter, the unit tests failed because Snapshooter internal routine using Newtonsoft is only reading the Newtonsoft.Json.JsonProperty attribute and ignore the replacement System.Text.Json.Serialization.JsonPropertyName
Thus, I could not 100% remove Newtonsoft dependency from my code and had to use both attributes as a workaround for Snapshooter, e.g. for one property in my model:
[System.Text.Json.Serialization.JsonPropertyName("deviceType")] [Newtonsoft.Json.JsonProperty("deviceType")] public string Type { get; set; }
Is there any plan to fully support System.Text.Json.Serialization on top of Newtonsoft.Json? Or at some point get rid of Newtonsoft?
The issue we are facing is, that we have Newtonsoft.Json integrated deeply in our core logic (for match options etc.) and therefore it will be difficult to change this. However, I will check this topic with the team.
The question is really how we want to do snapshots in the future. I think for snapshooter the attributes on an object should not matter since we want to get a raw snapshot of an object. System.Text.Json is geared towards performance in server applications. I really do not want to be dependant from a user standpoint of any of them. So let's discuss that internally ho we move forward on this one.
As far as I've investigated, it should be quite easy to accomplish this. In the first place you need to abstract the JToken handling away similarly like you did with everything else in the library (Serializer, FileHandler, FullNameResolver, etc.).
Could there be a out of the box configuration for this on which serializer should be used? We have some converters for Json.Text that we would have applied during serialization.
Perhaps better to avoid dependency to any specific serializer.
in principle I expected a object to be serializable as xml, csv and image and that match assertion simply to do a binary comparison.
Do not know the internals about this package, so good to have a high level description of what features benefit of Json.Net dependency
Perhaps better to avoid dependency to any specific serializer.
in principle I expected a object to be serializable as xml, csv and image and that match assertion simply to do a binary comparison.
Do not know the internals about this package, so good to have a high level description of what features benefit of Json.Net dependency
Its has a dependency to Newtonsoft not Json.Net and it serializes as Json not XML nor CSV.
Internals seem to be relying hardly on speciric features of Newtonsoft, that preventsnthe author to replace it. We wrote a wrapper but that works okish but would be nice to get a out of the box solution.