S.T.J source-gen reflection fallback and switching from AddContext to TypeInfoResolver

[pinkfloydx33]

I just updated System.Text.Json from 7.0.0-preview.6.22324.4 to 7.0.0-preview.7.22375.6 in my AspNet Core project. I am using Source Generation for the types consumed and produced by the controllers in my Web API project. During startup I configure MVC's JsonSerializerOptions by calling mvcOptions.JsonSerializerOptions.AddContext<MyJsonContext>(). All serialization is being performed by the infrastructure -- in other words I'm not calling JsonSerializer.Serialize manually.

When upgrading to the latest preview version, I began receiving exceptions for un-annotated root types that I apparently missed that were previously getting picked up by the reflection fallback--so a good thing. Some of our endpoints, however, produce MVC framework types (i.e. ProblemDetails) that we don't control. I was unable to add those types to my context as they have class-level converters (via attribute) which are internal and thus inaccessible to source-generation.

After re-reading through some of the issues/PRs in this repo, I changed my setup from this:

options.JsonSerializerOptions.AddContext<MyJsonContext>()

to this:

options.JsonSerializerOptions.TypeInfoResolver = JsonTypeInfoResolver.Combine(MyJsonContext.Default, new DefaultJsonTypeInfoResolver())

This seems to work and fallback to the reflection-based metadata for any types that were not annotated. So my questions:

• Am I correct that this will continue to use source-gen for annotated types and fallback to reflection otherwise?
• What are the implications of no longer using AddContext ?
• Is there a way around the inaccessible class-level converter issue for unowned types in general?

I tried digging through the code a bit and it seems like the only extra thing that AddContext does is bind the current options instance to the JsonSerializerContext. If de/serialization is happening using the overloads accepting the options (and not context/type info) and those options haven't changed (other than the switch to TypeInfoResolver) there should be no difference in output, right?

Some of this will eventually be moot as the types I'm having issues with are getting an overhaul in .NET 7. We're using the preview package due to some source-gen and data annotation fixes, but our adoption of .NET 7 won't be immediate. So I wanted to be sure that my understanding is correct and that the implications (if any) are clear. In the limited testing I've done everything seems to be working as expected but just want to be sure

@eiriktsarpalis

[eiriktsarpalis]

Am I correct that this will continue to use source-gen for annotated types and fallback to reflection otherwise?

That's right.

Is there a way around the inaccessible class-level converter issue for unowned types in general?

Not really, it might make sense to request a JsonSerializerContext exposed by the authors of the inaccessible class and then combine those with your own contexts.

I tried digging through the code a bit and it seems like the only extra thing that AddContext does is bind the current options instance to the JsonSerializerContext.

That's also true for the case of TypeInfoResolver. What AddContext does differently is that it initializes a brand new JsonSerializerContext which is bound to the current JsonSerializerOptions. This is done for backward compatibility but is not necessary for the context to generate metadata correctly, you can use TypeInfoResolver with pre-existing instances safely.

[pinkfloydx33]

Alright cool. I figured I had a good grasp here but didn't want to take things for granted. It's a shame I have to fallback to reflection -- sort of defeats the purpose of source gen, but it is what it is. Thanks again!