[API Proposal]: Allow C# models to be decorated with an attribute to indicate required code generation, not JsonSerializerContext

[mikegoatly]

Background and motivation

I've been looking at enabling trimming for some of our projects now we've migrated to .NET 6, and have found the current design for configuring the supported types on a JsonSerializerContext to be quite cumbersome.

Some of our projects have a reasonable, though not excessive, number of models that can be both serialized and deserialized from a third party API. This could be a single instance of the entity, or a list, which means that for every model we want to work with, we need to remember to decorate our context class as:

[JsonSerializable(typeof(Model1))]
[JsonSerializable(typeof(IList<Model1>))]
[JsonSerializable(typeof(Model2))]
[JsonSerializable(typeof(IList<Model2>))]
[JsonSerializable(typeof(Model3))]
[JsonSerializable(typeof(IList<Model3>))]
internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

The number of interaction points we have with the API will undoubtedly grow, and every time a new model is required, it's necessary to remember that there's another class somewhere that needs to have its list of attributes updated.

It the model class itself could be decorated with an attribute indicating the context that it needs to be part of, it would be much easier to remember, e.g.:

internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext)]
public class Model1
{
   /// ...
}

API Proposal

public sealed class JsonSerializerContextAttribute : JsonAttribute
{
    public JsonSerializerContextAttribute(Type jsonSerializerContextType, params Type[] additionalRootTypes);
}

API Usage

// Use the existing approach for the edge case where a model must *only* be serializable as part of a list and 
// serialization should throw an error if someone tries to serialize an entity outside of a list type
[JsonSerializable(typeof(IList<Model3>))]
internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

// A model that only is only ever (de)serialized as itself
[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext)]
public class Model1
{
   /// ...
}

// A model that could be deserialized as itself or a list
[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext), typeof(IList<Model2>)]
public class Model2
{
   /// ...
}

Alternative Designs

No response

Risks

No response

[ghost]

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

Issue Details

---

Background and motivation

I've been looking at enabling trimming for some of our projects now we've migrated to .NET 6, and have found the current design for configuring the supported types on a JsonSerializerContext to be quite cumbersome.

Some of our projects have a reasonable, though not excessive, number of models that can be both serialized and deserialized from a third party API. This could be a single instance of the entity, or a list, which means that for every model we want to work with, we need to remember to decorate our context class as:

[JsonSerializable(typeof(Model1))]
[JsonSerializable(typeof(IList<Model1>))]
[JsonSerializable(typeof(Model2))]
[JsonSerializable(typeof(IList<Model2>))]
[JsonSerializable(typeof(Model3))]
[JsonSerializable(typeof(IList<Model3>))]
internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

The number of interaction points we have with the API will undoubtedly grow, and every time a new model is required, it's necessary to remember that there's another class somewhere that needs to have its list of attributes updated.

It the model class itself could be decorated with an attribute indicating the context that it needs to be part of, it would be much easier to remember, e.g.:

internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext)]
public class Model1
{
   /// ...
}

API Proposal

public sealed class JsonSerializerContextAttribute : JsonAttribute
{
    public JsonSerializerContextAttribute(Type jsonSerializerContextType, params Type[] additionalRootTypes);
}

API Usage

// Use the existing approach for the edge case where a model must *only* be serializable as part of a list and 
// serialization should throw an error if someone tries to serialize an entity outside of a list type
[JsonSerializable(typeof(IList<Model3>))]
internal partial class ThirdPartyModelSerializationContext : JsonSerializerContext
{
}

// A model that only is only ever (de)serialized as itself
[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext)]
public class Model1
{
   /// ...
}

// A model that could be deserialized as itself or a list
[JsonSerializerContext(typeof(ThirdPartyModelSerializationContext), typeof(IList<Model2>)]
public class Model2
{
   /// ...
}

Alternative Designs

No response

Risks

No response

Author:	mikegoatly
Assignees:	-
Labels:	api-suggestion, area-System.Text.Json
Milestone:	-

[eiriktsarpalis]

It might be something we might consider, that being said there are a couple of drawbacks with that approach:

• The new attribute makes it possible to point to contexts not in the current project, which a source generator cannot support. It shouldn't be a huge issue assuming we detect this and provide a user friendly diagnostic explaining why this cannot work.
• It might negatively impact performance of the source generator, since it will need to look for and aggregate attributes from more types than just JsonSerializerContext.

cc @layomia @CyrusNajmabadi

[Sergio0694]

"It might negatively impact performance of the source generator, since it will need to look for and aggregate attributes from more types"

This can still be quite efficient on Roslyn 4.0 already (use CreateSyntaxProvider (example) filtering types with at least one attribute, then work on filtering those out), but especially with recent Roslyn versions there's now a new API specifically to look attributes up by fully qualified name in a very very fast way, see dotnet/roslyn#54725 🙂