Feeding source generated enum into json source generator

[JenyaRostov]

Hi, i have a source generator that generates enums based on classes i have in my project
In total i have 3 enums generated, one of which represents type of network request (one enum value per request class)
That enum is used in RequestMessage class, as a property
I get that class typeinfo by doing this: JsonContext.Default.GetTypeInfo(typeof(TRequest))
And this is the error i get: System.NotSupportedException: JsonTypeInfo metadata for type 'Proto.RequestType' was not provided by TypeInfoResolver of type 'Proto.JsonContext'

The main point of all of that is that i want to use that class(and generated enum) in a NativeAOT scenario, and for that i use json source generator. But you can't feed output of one SG to another, which leads to the question
How do i use that generated enum with json in NativeAOT? I tried custom converters (as suggested in discord), but that didn't work
The only solution i can think of is enabling reflection, but i don't know how to enable it

[elgonzo]

Note that this is not related to the runtime nor the BCL, and strictly speaking also not directly related to the C# language itself. This issue is related to the build pipeline (roslyn), and there is already (still) an open issue tracking this limitation: dotnet/roslyn#57239

[JenyaRostov]

Regarding the source generator question, yes. However the second part of my question is me asking for possible workarounds

[elgonzo]

However the second part of my question is me asking for possible workarounds

If you intend to stick with your enum source generator then it's a roslyn issue and should be asked there https://github.com/dotnet/roslyn/discussions

[JenyaRostov]

No, my other question is whether or not its possible to enable reflection based json in naot, which i still want an answer to

[elgonzo]

Oh my apologies, went off in the wrong direction there, evidently.

You could try use the reflection-based resolver (DefaultJsonTypeInfoResolver) instead of the source-generated SerializationContext.

However, you would also need to exclude from trimming and inlining of the type members participating in (de)serialization. Otherwise such members might be eliminated or inlined and not discoverable anymore during runtime by the reflection-based serializer. (https://stackoverflow.com/questions/77776702/net8-nativeaot-type-getproperties-doesnt-work-for-some-types-but-does-for-ot)

Not sure if there are other traps lurking when using DefaultJsonTypeInfoResolver-based (de)serialization with AoT, but if nobody else won't come up with a better suggestion, it's at least worth a try...

[JenyaRostov]

Thanks, gonna try that