Open craigambrose32 opened 3 years ago
Hello, I have the same issue. On the server side I use System.Text.Json and I generate the client using API Explorer. I see that enums with Flags are numbered starting from one, while non-Flags enum are numbered starting from zero effectively changing the original numbering. This happens when I enable the JsonStringEnumConverter on the server side. I guess the API Explorer just returns the string representation (my assumption) and NSwag doesn't know the original value.
Flags enums are not really supported by OpenAPI and support is only done half-way in NSwag/NJsonSchema.
I recommend to use an enum array instead of flag enums.
If the serializer uses string enums in the JSON representation, then the numbers in the client should not matter as it always serializes via string. For flag enums and string I do not know how the serializer represents multiple values in a single string - but it is probably not compliant/not possible to describe with OpenAPI.
Hi Rico, thanks for your answer. In my project, System.Text.Json serialize Flags separating values with a comma. Not sure if it's compliant but it works.
The original value matter if it's used against a database or, as in my case, to communicate with a device. Not the best practice for sure but it's like this in real world.
Finally I was inspecting the EnumMember attribute and there's no property to carry its original value... I ended up modifying my Flags enum to start from one (removing the None value). I guess it's just something to remember ;)
I'm using NSwag.CodeGeneration.CSharp v13.9.4 to generate a C# Http Client. Here is how I generate the client code:
The originating C# enum and class looks like this (Note: the enum values are not sequential):
With a simple controller that looks like this
My server returns strings for the enum properties globally. So, I haven't added the annotation to either the enum definition or the references in the
Input
class. i.e.Ultimately I end up with an OpenAPI spec that looks like this
Now when I generate the C# client code I end up with this for the enum and class (Note: the enum values are now sequential and don't match the originating class nor the values in the OpenAPI spec, although the EnumMember value does)
If I change the OpenAPI spec to have the type of the enum be an
integer
like this:Then I get generated code like this that seems correct:
But I'd really like the OpenAPI spec to reflect that the enum values will typically be their string representations. Is this a bug with how the values of the enum are being generated? This is causing some problems on the caller side as I'd like the enum in the generated code to be the source of truth for what the underlying integer values are.