-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different StringEnumConverter-Behavior between STJ / Newtonsoft #2820
Comments
This might be related to dotnet/runtime#47765 and this comment: Lines 60 to 67 in a17b464
It's possible this is fixed by #2799, otherwise we might have to see if there's any changes needed to if the assertion in that comment is no longer true. |
You may have to opt-in to this behaviour with |
Thank you so much for checking! Butt sorry, not quite sure what you mean? I've set The serializer itself works (using .Net 8.0, but also checked 7 & 6), generating strings for the keys. |
I could sure support here with a PR :) Can you give me a hint where to start? |
I'm not sure where specifically without starting to debug it myself. |
Switching my project from Newtonsoft to STJ, I noticed the following different behavior between the two scheme generators:
Adding the
JsonStringEnumConverter
makes Swashbuckle aware of enums being serialized as string - so far, so good. But the STJ schema builder doesn't seam to be aware ofIDictionary<[Enum], int>
.For Newtonsoft the following scheme was generated:
Now I only get
So it's still being recognized as an object containing integer properties. Better than nothing. But the old scheme was way more explicit.
The text was updated successfully, but these errors were encountered: