Support ObjectCreationHandling in JsonSerializerOptions like Json.NET does

[tig]

Json.NET supports ObjectCreationHandling options, but System.Text.Json does not.

https://www.newtonsoft.com/json/help/html/DeserializeObjectCreationHandling.htm

That's disappointing.

Or, am I missing something?

[ahsonkhan]

ObjectCreationHandling itself is not supported in JsonSerializerOptions today. This is primarily because we didn't see much need for it to prioritize it (you are the first one asking), and of course there are a whole bunch of Json.NET features that S.T.Json doesn't support right out the gate as its first release (some of which we probably won't ever support).

What feature of ObjectCreationHandling do you use and can you share more details around your scenario? What types/collections do you want to serialize/deserialize and what behavior do you expect?

It would help us prioritize the feature and potentially see if there is a viable solution/workaround for you if we can understand your use case (rather than trying to answer a question like: Why is feature X from Json.NET not supported).

For example, are you deserializing lists? Do you want the Reuse behavior or the Auto/Replace behavior? S.T.Json replaces your existing list/collection contents and deserializes based on what's in the JSON payload.

cc @layomia

[tig]

I hadn't actually used Json.NET's ObjectCreationHandling support and may have mis-interpreted what it did. I thought it gave an option for me to deserialize into an existing object instance. E.g. (psuedocode):

class Doc{ 
    public string Title;
    public string Type;
}
...
// jsonString holds instance where doc.Type = "Foo";
Document doc = new Document() { Title = "Title" };
Deserialize<Document>(doc, jsonString);

With this, doc would have doc.Title == "Title" and 'doc.Type == "Foo"`.

Forgive me if I misunderstood. But this is what I'm looking for. I don't want Deserialization to create a new instance, but update an existing instance.

[ahsonkhan]

Duplicate of https://github.com/dotnet/corefx/issues/37627

Let's move the discussion there.