.NET 7 polymorphic serialization support via System.Text.Json

[shoaibshakeel381]

Pre .NET 7, System.Text.Json does not support polymorphic serialization, while support was added in .NET 7 (currently RC2), it requires either using attributes on base class or by using custom IJsonTypeInfoResolver. Reason given for this behaviour was that polymorphic-serialization is unsecure and might expose sensitive data. So it has to be an opt-in feature.

But I'm a bit confused about the approach taken by .NET 7 to allow opt-in. .NET 7 solution looks like this:

[JsonDerivedType(typeof(WeatherForecastWithCity))]
public class WeatherForecastBase
{
    public DateTimeOffset Date { get; set; }
    public int TemperatureCelsius { get; set; }
    public string? Summary { get; set; }
}

public class WeatherForecastWithCity : WeatherForecastBase
{
    public string? City { get; set; }
}

var data = new WeatherForecastWithCity  {...}
var jsonString = JsonSerializer.Serialize<WeatherForecastBase>(data);

Which produce this result:

{
  "City": "Milwaukee",
  "Date": "2022-09-26T00:00:00-05:00",
  "TemperatureCelsius": 15,
  "Summary": "Cool"
}

But now we have to declare derived class in JsonDerivedTypeAttribute on base class. This limits usuability of this feature, especially if both classes reside in separate assemblies. Wouldn't it have been a better option to add an attribute on base class to indicate that polymorphic serialization is allowed and then derived class can also have another attribute if it wants to opt-in to it? like this:

// ofc, attribute names are just for explanation
[PolymorphicJsonSerialization]
public class WeatherForecastBase
{
    public DateTimeOffset Date { get; set; }
    public int TemperatureCelsius { get; set; }
    public string? Summary { get; set; }
}

[PolymorphicJsonSerialization(PolymorphicJsonSerializationMode.Enabled)]
public class WeatherForecastWithCity : WeatherForecastBase
{
    public string? City { get; set; }
}

This makes sure that derived classes can't just enable this feature by themselves and still keep security concerns in mind. This approach will also allow us to use polymorphics serialization even if both classes are in separate assemblies, while derived class assembly references base class one.

So my question is why was current approach selected when it is still so limited.

[krwq]

How far in the hierarchy would you allow it? Would you allow your class to deserialize into i.e. value in Dictionary<string, object>

[shoaibshakeel381]

I see, current approach allows to control which specific derived classes are allowed for polymorphic serialization. So this comes at the cost of not supporting cases when both classes are in different assemblies.

Would've still prefered to have both approaches, and base class can declare which mode is allowed. Like

[PolymorphicJsonSerialization(Mode.Open)] // Open mode for all derived classes
public class WeatherForecastBase
{
    public DateTimeOffset Date { get; set; }
    public int TemperatureCelsius { get; set; }
    public string? Summary { get; set; }
}

[PolymorphicJsonSerialization(Mode.Declared)] // declared mode to only allow declare types
[JsonDerivedType(typeof(WeatherForecastWithCity))]
public class WeatherForecastBase
{
    public DateTimeOffset Date { get; set; }
    public int TemperatureCelsius { get; set; }
    public string? Summary { get; set; }
}

After all 99% of time, bases classes do not contain sensitive information and polymorphics serialization is the expected behaviour

[eiriktsarpalis]

So my question is why was current approach selected when it is still so limited.

See a similar question and the response here. TL;DR there's a few reasons:

1. There would be ambiguity about what the polymorphic base type should be.
2. It would be challenging to traverse the entire cross-assembly open hierarchy at runtime to detect all derived types decorated with the attribute. This is particularly true for the case of the source generator, for which derived types might not even be visible at compile time.
3. This pattern was chosen intentionally to encourage users to model their DTO hierarchies in a single location.

For users that do require cross-assembly type hierarchies, it should still be possible to define them using contract customization.

[shoaibshakeel381]

thanks for the links and explanation.