msgraph-sdk-dotnet icon indicating copy to clipboard operation
msgraph-sdk-dotnet copied to clipboard

Serialization interface is incomplete

Open ashikns opened this issue 6 years ago • 5 comments

Graph sdk exposes an ISerializer interface and you can pass an implementation of it using your own custom json library. But the problem is the graph source code uses a lot of Json.Net annotations and custom converters. None of this compatible with any other serialization library plus it creates a hard dependency on Json.Net. Can the serialization be made fully independent of Json.Net? AB#7317

ashikns avatar Feb 21 '19 12:02 ashikns

Agreed, we have been running into this as well when using the Graph .NET SDK with Unity. 😕

ISerializtion promises an interface but then actually relies on a certain implementation of it. Not good.

reneschulte avatar Feb 21 '19 13:02 reneschulte

Thank you for raising this issue. We would really like to find a good resolution to this.

You could argue that any deserializer could read the JSON.NET annotations on the classes and use that metadata to drive the deserialization process. However, I accept this isn't a great solution.

We have discussed the possibility of generating explicit serialization/deserialization code into the models so that we can avoid the the use of JSON.NET's object serializer. We would only use JSON.NET to parse JSON strings into a generic DOM of objects, arrays, properties and values. This would make it much easier to plug in alternative JSON parsers.

If you have any other suggestions as to how make our serializer easily replacable, we would love to hear them.

darrelmiller avatar Mar 06 '19 19:03 darrelmiller

Thanks @darrelmiller for the further info.

We ended up going with the approach you mentioned in your first paragraph and basically rolled our own JSON.NET attribute parser based on Utf8Json but we don't like that of course and would much prefer a better plug-able architecture in the MS Graph APIs. Not sure if the attributes are needed and if they can be removed to make the Graph JSON more standard-compliant. Otherwise maybe some callback functions could work that are called for the explicit serialization for specific attributes. It's a tough one indeed.

reneschulte avatar Mar 07 '19 07:03 reneschulte

@andrueastman Do the v4 changes support bring your own serializer? In the Use a custom IResponseHandler section, we can use WithResponseHandler per response, but is there a way to set the serializer for requests, as well as globally on the client so we don't have to make per request calls using WithResponseHandler?

MIchaelMainer avatar May 03 '21 16:05 MIchaelMainer

@MIchaelMainer Apart from the use of a custom IResponseHandler, to use a different serializer globally, an SDK user would still have to implement the ISerializer interface and replace the default in the Serializer during the GraphClient initialization.

andrueastman avatar May 04 '21 07:05 andrueastman

This is resolved with the Kiota based versions of the SDK.

The generated models no longer include annotations directly referencing types/custom converters from System.Text.Json/Json.Net but involves generating explicit serialization/deserialization code into the models (example here).

By providing custom implementations for IParseNodeFactory/IParseNode for deserialization and ISerializationWriterFactory/ISerializationWriter for serialization, one may simply register the custom implementations as done in the link below to use with the SDK.

https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/c4414be6c6c845b6d69f08e2c6ca61548a1f304a/src/Microsoft.Graph/Generated/BaseGraphServiceClient.cs#L371

andrueastman avatar Aug 30 '22 09:08 andrueastman