System.Text.Json serialization

[Acerby]

System.Text.Json serialization options/features have improved a great deal in recent releases. Also the new ability to customize via the Modifiers is great. However there are some things I find are currently annoying/awkward to do.

1. Its now possible to use the "IgnoreReadOnlyProperties" option when serializing. This is often useful especially when combined with the option to serialize fields. In practice I found the whilst I am happy with this as a default, I would often like to override that default those settings for some specific properties. The obvious solution would appear to be to add a [JsonInclude] attribute in those scenarios, however currently that results with a runtime exception being thrown saying it conflicts with the options specified. Personally I would much rather that the options be treated as a default that I could override locally rather than a strict requirement. Is there some we might need require these options to be "always" rather than "bydefault"? If so then perhaps we can support both?

2. Its great we can now chose to handle references by using "$id" to avoid duplication and circular reference issues. We also have another great feature that we can choose to update ("populate") an object rather than always create new objects. However it seems we cant currently combine those two types within one serialization tree. The scenario I was working with required one of the object types to be "updated" rather than "created" on deserialization. (I did eventually manage to work around this using jsonTypeInfo.create but is a very nasty/flaky hack.) However It feels like I should have just been able to add [JsonObjectCreationHandling(JsonObjectCreationHandling.Populate)] to the property in question and be done with it.

3. Another great feature that has been made available is the ability to override object creation using the jsonTypeInfo.create property.
   This is obviously potentially useful in a wide range of scenarios, such as using object pools, or to customize creation possibly by providing additional data, that was not part of what was serialized. This would be much more powerful however if the overridden create function was supplied with arguments giving the context of what property of which instance was being serialized. This would make it easier/cleaner when the object being created depends on its context in or on data contained within the ancestor tree. It would also be nice if there was a way to more simply/directly supply it with custom data supplied when the serialize is invoked. Eg by supporting an additional optional generic context argument passed to the serialize/de-serialize method, that could then be passed to serialized objects.

[huoyaoyuan]

@dotnet/area-system-text-json

[eiriktsarpalis]

Hi @Acerby! In order for us to be able to better look at your feedback, I would recommend filing separate issues for each of the proposals/bug reports. These should ideally include minimal reproductions comparing expected behavior vs. actual behavior. Thanks!