How to use TypeNameHandling to TypeNameHandling.Auto for deserialization only

I need to set the TypeNameHandling to TypeNameHandling.Auto to deserialize my objects returned by elasticsearch. I set the settings

new ConnectionSettings(uri).SetJsonSerializerSettingsModifier(s => s.TypeNameHandling = TypeNameHandling.Auto)

But this also change the type name handling of when sending the query. So Nest sends the query with multiple $type in it which doesn’t work :

{
  "_source": {
    "$type": "Nest.SearchSourceDescriptor`1[[Pelican.Web.Models.Search.EntityContainer`1[[Pelican.Models.FormModel, Pelican.Models]], Pelican.Web]], Nest",
    "include": [
      "Name",
      "Date",
      "Data"
    ]
  },
  "query": {
    "filtered": {
      "$type": "Nest.FilteredQueryDescriptor`1[[Pelican.Web.Models.Search.EntityContainer`1[[Pelican.Models.FormModel, Pelican.Models]], Pelican.Web]], Nest",
      "filter": {
        "terms": {
          "Name": [
            "Document name"
          ],
          "execution": "or"
        }
      }
    }
  }
}

So, how can I set the deserialization settings of Newtownsoft without touching the serialization?

[Mpdreamz]

Instead of globally setting the the type name handling you can also mark properties with:

[JsonProperty(TypeNameHandling = TypeNameHandling.Auto)]

There is also a ItemTypeNameHandling option if you are working with collections.

This is the safer way adding support for this only local to your objects.

Hope this solves your issue!

[Mpdreamz]

Ok then while not a bug it should be a feature request on JSON.NET to be able to specify it at the interface level.

I understand your frustration but we are all users of json.net here and your needs should be able to be specified locally on your scope only. By saying to us you expect to to alter a pretty intrusive setting globally without altering how our objects are serialized you are looking at it the wrong way IMO.

You can write a custom converter for now and apply it to your IMyInterfaceType for the time being. With NEST 2.0 we are exploring options at generating the serializing/deserialization of our objects ahead of time (no longer relying on JSON.NET defaults (perhaps not using JSON.NET at all)) but this will take a while to implement.