STJ Source Generator fails to do polymorphic serialization for built-in types

[aromaa]

Description

The System.Text.Json source generator fails to serialize list of objects (List<object>) that contains only built-in types like string. This can be worked around by adding the types to the JsonSerializerContext with the JsonSerializable attribute but this feels counterintuitive and doesn't look great and bloats the class. This scenario works just fine without source generators.

Repo

internal static class Program
{
    private static void Main()
    {
        JsonSerializer.Serialize(new List<object>
        {
            "hey"
        }, typeof(List<object>), JsonContext.Default);
    }
}

[JsonSerializable(typeof(List<object>))]
[JsonSerializable(typeof(string))] //Commenting this line breaks the program
internal sealed partial class JsonContext : JsonSerializerContext
{
}

[ghost]

Tagging subscribers to this area: @eiriktsarpalis, @layomia
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

The System.Text.Json source generator fails to serialize list of objects (List<object>) that contains only built-in types like string. This can be worked around by adding the types to the JsonSerializerContext with the JsonSerializable attribute but this feels counterintuitive and doesn't look great and bloats the class. This scenario works just fine without source generators.

Repo

internal static class Program
{
    private static void Main()
    {
        JsonSerializer.Serialize(new List<object>
        {
            "hey"
        }, typeof(List<object>), JsonContext.Default);
    }
}

[JsonSerializable(typeof(List<object>))]
[JsonSerializable(typeof(string))] //Commenting this line breaks the program
internal sealed partial class JsonContext : JsonSerializerContext
{
}

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

[eiriktsarpalis]

Agreed that the user experience could be improved here, however the error message:

System.NotSupportedException: Metadata for type 'System.Int32' was not provided to the serializer. The serializer method used does not support reflection-based creation of serialization-related type metadata. If using source generation, ensure that all root types passed to the serializer have been indicated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically. The unsupported member type is located on type 'System.Object'. Path: $.

indicates that this is clearly by design. Given that we have a workaround, recommend moving this to 7.0.0. cc @layomia @steveharter

[eiriktsarpalis]

Related to #30083.

[layomia]

Yes it is by design - for polymorphic serialization scenarios, we need to know all possible runtime types ahead of time via JsonSerializableAttribute.

What sort of improved user experience would we like to see here - a diagnostic warning when compiling and object is found as a top-level type for source generation? I think that could be a nuisance in the case where a user has already provided the runtime type.

[aromaa]

It feels unintuitive to need to add the basic primitives and commonly used built-in types with the JsonSerializableAttribute that support serialization out of the box.

It would make sense that these are pre-included or that theres a switch to generate them without the need to manually include them all (which there are dozens of)

[eiriktsarpalis]

It feels unintuitive to need to add the basic primitives and commonly used built-in types with the JsonSerializableAttribute that support serialization out of the box.

I guess it depends on what "commonly used built-in types" means. We might consider adding common primitives and string OOTB but want to avoid rooting all of BCL by baking in support for things like DateTimeOffset or Guid. It is also impossible to do it for user-defined POCOs or generic types like Dictionary.

It makes me think that users will encounter this issue one way or another, so there doesn't seem to be a lot of value in baking in support for what might amount to 20% of commonly used runtime types for object.

[aromaa]

I guess it depends on what "commonly used built-in types" means. We might consider adding common primitives and string OOTB but want to avoid rooting all of BCL

Considering the rooting problem, I think it would relieve the pain point mostly by just including the primitives and string. It would be nice if there was a trimming attribute to mark things as "weak" where they need to be rooted elsewhere to not get trimmed.

It is also impossible to do it for user-defined POCOs or generic types like Dictionary.

I'm not sure I follow? As long as the underlying type for object is found from the GetTypeInfo it will generate JSON just fine for types like List<object>. What I'm asking is to fallback to some BCL code to fill in the blanks for primitives or just include them by default in the generator.

It makes me think that users will encounter this issue one way or another, so there doesn't seem to be a lot of value in baking in support for what might amount to 20% of commonly used runtime types for object.

The primitives and string are the most common types of them all so including at least them seems to make sense to me. If we end up needing to explicitly specify types like DateTimeOffset or Guid it seems okay-ish to me but having to do it for primitives doesn't feel right to me.

[eiriktsarpalis]

We won't have time to work on this for .NET 7, moving to Future.

[layomia]

Closing as by-design: implicit handling by the source generator is avoided. It is beneficial to pay attention to polymorphism occurring in serialization routines.

Including primitives by default might have an impact on size-related issues - #77897.

There's a tracking issue to consider issuing a diagnostic warning when typeof(object) is encountered in the generator's input type graph - #53935.