Provide trim/AOT-safe mechanism to (de)serialize enums from strings with JSON source-gen

[layomia]

See #79311 (comment) for an updated API proposal.

Original Proposal

Background and Motivation

The JsonStringEnumConverter class is a built-in JsonConverterFactory that is not compatible with NativeAOT, since it relies on Type.MakeGenericType() to work. We need to update the source generator so that it intercepts [JsonConverter(typeof(JsonStringEnumConverter))] annotations and replaces them with a NativeAOT-safe factory method invocation.

Should be addressed in conjunction with #81833.

API Proposal

namespace System.Text.Json.Serialization.Metadata;

public static class JsonMetadataServices
{
    public static JsonConverter<T> GetEnumConverter<T>(JsonSerializerOptions options) where T : struct, Enum
+   public static JsonConverter<T> GetStringEnumConverter<T>(JsonStringEnumConverter converterFactory, JsonSerializerOptions options) where T : struct, Enum
}

Alternative Design

We could add the generic factory method on the converter factory itself:

public class JsonStringEnumConverter
{
    public JsonConverter CreateConverter(Type typeToConvert, JsonSerializerOptions options);
+   public JsonConverter<T> CreateConverter<T>(JsonSerializerOptions options) where T : struct, Enum
}

However I would prefer if this call were hidden behind the EditorBrowsable.Never JsonMetadataServices class.

Edited by @eiriktsarpalis

Original Proposal

Forking from https://github.com//issues/73124 which goes over a friendly, general pattern for JsonConverterFactory usage with source-gen.

This issue focuses on a plan to support [JsonStringEnumConverter] (or an alternate approach), the primary scenario needed in 8.0 for the ASP.NET effort for AOT friendlinessfriendliness (JSON items tracked by #79122).

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

---

Forking from #73124 which goes over a friendly, general pattern for JsonConverterFactory usage with source-gen.

This issue focuses on a plan to support [JsonStringEnumConverter] (or an alternate approach), the primary scenario needed in 8.0 for the ASP.NET effort for AOT friendliness.

Author:	layomia
Assignees:	-
Labels:	area-System.Text.Json, trimming-for-aot, source-generator, partner-impact
Milestone:	8.0.0

[Sergio0694]

Curious about this since we're also deserializing a bunch of enums from strings in the Store. The way we're currently doing this (to keep backwards compatibility with Newtonsoft.Json) is by having a custom ResilientStringEnumConverter<T> that implements a Newtonsoft-compatible (ie. case invariant and also supporting reading from numbers) converter for enums. Then we use it like so:

[JsonConverter(typeof(ResilientStringEnumConverter<SomeEnum>))]
enum SomeEnum
{
    A,
    B,
    C
}

This works just fine including with trimming (we're using .NET Native and it works with no issues as far as we can tell), and by inspecting the generated code we can see that in fact the generator is creating an instance of each specialized converter for each property of one of our enum types.

So just to understand this better, is the goal of this issue to add support for this in a way that it also works when eg. passed via a non-generic context (eg. via the options) or when annotating an enum type with the non-generic converter type? As in, it seems like this is otherwise already supported and working fine with trimming on AOT as long as you annotate each enum type with the correct generic converter already? 🤔

Just trying to get a better understanding on this 🙂
Thank you!

[layomia]

The goal is to have usage of [JsonStringEnumConverter] work well with AOT. The issue is that converter factories often create converter instances using reflection (problem for AOT). This is most commonly due to needing to fill a generic T (the type to (de)serialize, in this case enums) dynamically at runtime.

[Sergio0694]

"The goal is to have usage of [JsonStringEnumConverter] work well with AOT."

Just to elaborate on what I meant - it seems to me there's two different issues with respect to enum serialization, which don't necessarily need the same solution, as it doesn't have the same complexity. What I meant is that:

• If you want to support just adding JsonStringEnumConverter to the JSON options and have it "just work" at runtime on any enum type while still being trimmable and needing no reflection, then yes some new factory API is needed for this.
• If you just want to support this over specific enum types or properties, I don't think anything else is needed other than just making JsonStirngEnumConverter<T> public. That's already fully trimmable and with no reflection needed. In fact you can already do this today by just writing your own enum converter that works the same way (we're doing this extensively in the Microsoft Store, for instance).

For point 2, that is, like I mentioned in my previous example, if you have:

[JsonConverter(typeof(JsonStringEnumConverter<MyEnum>))]
public enum MyEnum { A, B }

Then the source generator will just generate code to construct a new JsonStringEnumConverter<MyEnum> converter at runtime, which is already fully trimmable since the generic type is already statically constructed. Eg. in the Store we have our own CaseInvariantEnumConverter<T> and ResilientCaseInvariantEnumConverter<T> types which we added as annotations over all our enum types as needed, and that works just fine with trimming and AOT.

To clarify - I'm not saying that a general factory pattern isn't needed, but just that in case it might be useful to break this work down into smaller units, the second part can be made to work without the need for any new APIs/patterns, is all 🙂