Text.Json Serialization Context and Reference Handler

[Acerby]

There appears to be an fundamental issue with using JsonConvert based implementations to provide custom serialization for types, in that it there is no way to access or preserve the current serialization context. Thus if the object you are serializing refers to other objects then there is no way to ensure those child object (and their subtrees) would be serialized ( or deserialized) in the same way they would have been in you hadn't customized the intervening object. You cant for example simply fall-back to what the original implementation would have been for child references. The only option appears to be create a totally new serialization context for serializing the child objects.
This limitation is particularly problematic for situations where an object is referenced in multiple places and the inbuilt reference handler logic is then used to link up these references because this mechanism is obviously context dependent, and there appears to be no way to obtain a reference to the current resolver from within the JsonConvert class. Thus this appears to fundamentally break the ability to customize serialization of mid-tree objects when using the reference handler logic.
Having some sense of the current context would also be helpful in other contexts/scenarios also. For example its not uncommon for some objects to have originally been built with references to ancestor objects, or in some cases objects outside of the immediate scope being serialized. Alternatively it might be desired to serialize an object in more than one way depending on usage scenario, again requiring a dependency on some kind of serialization context.

FYI: https://github.com/Jozkee

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There appears to be an fundamental issue with using JsonConvert based implementations to provide custom serialization for types, in that it there is no way to access or preserve the current serialization context. Thus if the object you are serializing refers to other objects then there is no way to ensure those child object (and their subtrees) would be serialized ( or deserialized) in the same way they would have been in you hadn't customized the intervening object. You cant for example simply fall-back to what the original implementation would have been for child references. The only option appears to be create a totally new serialization context for serializing the child objects.
This limitation is particularly problematic for situations where an object is referenced in multiple places and the inbuilt reference handler logic is then used to link up these references because this mechanism is obviously context dependent, and there appears to be now way to obtain a reference to the current resolver from within the JsonConvert class. Thus this appears to fundamentally break the ability to customize serialization of mid-tree objects when using the reference handler logic.
Having some sense of the current context would also be helpful in other contexts/scenarios also. For example its not uncommon for some objects to have originally been built with references to ancestor objects, or in some cases objects outside of the immediate scope being serialized. Alternatively it might be desired to serialize an object in more than one way depending on usage scenario, again requiring a dependency on some kind of serialization context.

FYI: https://github.com/Jozkee

Author:	Acerby
Assignees:	-
Labels:	area-System.Text.Json, untriaged
Milestone:	-

[eiriktsarpalis]

Essentially a duplicate of #51715. We won't be able to support this unless we expose methods on JsonConverter that accept serialization state objects; this is tracked by #63795