System.Text.Json AOT Polymorphic serialization

[markdibarry]

Description

I'm making an AOT compatible library. This library contains a base type that users inherit from for their own custom classes. This type needs serialized, but considering the base type and the derived types are in different assemblies, the base type doesn't have knowledge of the derived types at compile time. I want it to be easy for the user to register types, avoiding requiring users to have a deep understanding of the System.Text.Json API so I've provided a static method they can use to register their custom classes through. When serializing, I have added a modifier to the BaseTypeContext's default resolver, which adds the registered derived type to the base type's PolymorphismOptions, but it's never being called. This works in a non-source gen context, but for source gen, it appears to need to know about all derived types to call the Modifier, and it needs the modifier to be called to know about any derived type.

I saw this old issue, but it looks like the user stopped replying and the last suggestion seemed to still require references to the user's custom classes in the base assembly, which isn't feasible. Is the only currently supported way to achieve AOT-compatible cross-assembly polymorphic serialization to put the burden mainly on the user, or is there another way I'm missing?

Reproduction Steps

using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.Json.Serialization.Metadata;

BaseType.Register<DerivedType>();
JsonSerializerOptions options = new()
{
    WriteIndented = true,
    TypeInfoResolver = BaseTypeContext.Default
        .WithAddedModifier(static ti =>
        {
            // Never reached
            if (ti.Type.IsAssignableTo(typeof(BaseType)))
            {
                ti.PolymorphismOptions = new JsonPolymorphismOptions
                {
                    TypeDiscriminatorPropertyName = "DerivedType",
                    IgnoreUnrecognizedTypeDiscriminators = true,
                    UnknownDerivedTypeHandling = JsonUnknownDerivedTypeHandling.FailSerialization,
                };

                foreach (var type in BaseType.DerivedTypes)
                    ti.PolymorphismOptions.DerivedTypes.Add(type);
            }
        }
    )
};

DerivedType derivedType = new(4, "Foo");
// Exception thrown, says 'JsonTypeInfo metadata for type 'DerivedType' was not provided'
string ser = JsonSerializer.Serialize(derivedType, options);
Console.WriteLine(ser);
Console.ReadLine();

// Base Assembly
public class BaseType(int myInt)
{
    private static List<JsonDerivedType> _derivedTypes = [];
    public static IReadOnlyList<JsonDerivedType> DerivedTypes => _derivedTypes;

    public static void Register<T>()
    {
        Type type = typeof(T);
        _derivedTypes.Add(new JsonDerivedType(type, type.Name));
    }

    public int MyInt { get; set; } = myInt;
}

[JsonSerializable(typeof(BaseType))]
public partial class BaseTypeContext : JsonSerializerContext
{
}

// User Assembly
public class DerivedType(int myInt, string myString) : BaseType(myInt)
{
    public string MyString { get; set; } = myString;
}

Expected behavior

Calls the modifier and serializes the type.

Actual behavior

Never calls the modifier and throws exception when serializing.

Regression?

No.

Known Workarounds

You can change the source gen context to a DefaultJsonTypeInfoResolver or chain them together, but this breaks AOT compatibility and does not serialize any derived properties.

The other work around is to put the burden on the user and assume they have a deep understanding of System.Text.Json and are okay with splitting registration of each type across all of their custom classes via attributes. Of course, this is less than ideal though.

Configuration

This is a standard .NET 9 console app. Attempted on Linux and Windows x64.

Other information

N/A

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[eiriktsarpalis]

In the context of AOT, apart from declaring a derived type you also need to tell the serializer how that derived type is meant to be serialized. This involves having the user define their own context for DerivedType and pass that into JsonSerializerOptions as well. In your example, this would involve having the Register<T>() method additionally accept a JsonSerializerContext argument which is then appended to the TypeInfoResolverChain property in your JsonSerializerOptions.

[markdibarry]

That's unfortunate. It sounds like it defeats the purpose of me abstracting it to a method in the first place. If anything, it just adds an extra step and now forces the user to split their STJ configuration across multiple files and in one extra registration method I've created.

Then from what I gather, in STJ's current implementation, if you have cross-assembly polymorphism in a program targeting AOT, there's no way to get around requiring the library consumer to have prerequisite knowledge of how STJ works in source-gen mode and will always require some manual work on their end. I try to avoid these sorts of things for users since a library/system/etc is always much less likely to be adopted the more difficult it is to get started. Luckily, it sounds like it's a niche situation, but (unluckily) it's my situation. Hopefully, STJ will get there someday. I appreciate the information!

[elgonzo]

Just an FYI:

Since you don't have control over how the users of your library implement their derived types and what property names they will come up with, using a TypeDiscriminatorPropertyName that is a valid identifier in C#/F# could possibly lead to conflicts if for whatever reason some user chooses to implement a derived type with a property of exactly the same name. I don't know how likely that scenario would be, but unless you are required to use exactly this TypeDiscriminatorPropertyName, why leave it to chance (and needing to make your users aware of this) if you could avoid this outright by choosing one that is not a valid C#/F# identifier.

[markdibarry]

For sure. I've seen this recommended often and personally do this for my project. It's a rare case, but no need to limit if you don't need to.