CSharp | Enum values are invalid after being sanitized

[vadrsa]

First of all, thanks for such a great tool!

Enum values are being sanitized, but don't have an EnumMember Attribute on top of them to specify the original name from the spec.
Enum value sanitization is also a bit off in my opinion.
For example,
OpenAPI spec

"enum": [
    "DISABLED",
    "CONSIDERING",
    "UNKNOWN",
    "PLAN:EXECUTING:STOPPING",
    "PLAN:EXECUTING:STOP_FAILED",
    "PLAN:EXECUTING:STOPPED",
    "PLAN:EXECUTING:STOPPED:AWAITING_PRICES",
    "PLAN:EXECUTING:STARTING",
    "PLAN:EXECUTING:START_FAILED",
    "PLAN:EXECUTING:STARTED",
    "PLAN:EXECUTING:CHARGE_INTERRUPTED",
    "PLAN:EXECUTING:OVERRIDDEN",
    "PLAN:ENDED:FINISHED",
    "PLAN:ENDED:UNPLUGGED",
    "PLAN:ENDED:FAILED",
    "PLAN:ENDED:DISABLED",
    "PLAN:ENDED:DEADLINE_CHANGED"
],

is converted to

public enum EnumName{
    DISABLED,
    CONSIDERING,
    UNKNOWN,
    PLANEXECUTINGSTOPPING,
    PLANEXECUTINGSTOP_FAILED,
    PLANEXECUTINGSTOPPED,
    PLANEXECUTINGSTOPPEDAWAITING_PRICES,
    PLANEXECUTINGSTARTING,
    PLANEXECUTINGSTART_FAILED,
    PLANEXECUTINGSTARTED,
    PLANEXECUTINGCHARGE_INTERRUPTED,
    PLANEXECUTINGOVERRIDDEN,
    PLANENDEDFINISHED,
    PLANENDEDUNPLUGGED,
    PLANENDEDFAILED,
    PLANENDEDDISABLED,
    PLANENDEDDEADLINE_CHANGED,
}

Proposed enum in chsarp

public enum EnumName{
    [EnumMember(Value = "DISABLED")]
    DISABLED,
    [EnumMember(Value = "CONSIDERING")]
    CONSIDERING,
    [EnumMember(Value = "UNKNOWN")]
    UNKNOWN,
    [EnumMember(Value = "PLAN:EXECUTING:STOPPING")]
    PLAN_EXECUTING_STOPPING,
    [EnumMember(Value = "PLAN:EXECUTING:STOP_FAILED")]
    PLAN_EXECUTING_STOP_FAILED
    ///...
}

The naming is a bit subjective, but it would be cool if Kiota could be more extensible, so one could write some code to customize the generation or namings.

[baywet]

Thanks for reporting this and for the praises! I believe the issue is multiple folds:

1. The CSharp symbol is not normalized as expected by conventions PLAN:ENDED:DEADLINE_CHANGED should become PlanEndedDeadlineChanged
2. The Serialization value is not caried over, leading to inaccurate parsing/serialization

I'm going to focus on the second aspect as it's a more pressing issue at the moment.
If this is something you'd like to help address with a couple of pull requests, here are some pointers:

The code that could write the enum member attribute lives here

kiota/src/Kiota.Builder/Writers/CSharp/CodeEnumWriter.cs

Line 30 in 0089687

writer.WriteLine($"{option.Name.ToFirstCharacterUpperCase()}{(codeElement.Flags ? " = " + GetEnumFlag(idx) : string.Empty)},");

It should rely on this information and only add an annotation if this property is true.

kiota/src/Kiota.Builder/CodeDOM/CodeEnumOption.cs

Line 16 in 0089687

public bool IsNameEscaped

Unit tests can be added here.

kiota/tests/Kiota.Builder.Tests/Writers/CSharp/CodeEnumWriterTests.cs

Line 11 in 0089687

public class CodeEnumWriterTests : IDisposable

Lastly the serialization will need to be updated to handle that case.
https://github.com/microsoft/kiota-serialization-json-dotnet/blob/e26135c0ab1edc8cad5a70cacd7964b16dddce3b/src/JsonSerializationWriter.cs#L241
https://github.com/microsoft/kiota-serialization-json-dotnet/blob/e26135c0ab1edc8cad5a70cacd7964b16dddce3b/src/JsonParseNode.cs#L157

Are you willing to submit a couple of pull requests to address this?

CC @andreaTP and @andrueastman for visibility.

[vadrsa]

Thanks for the quick response and the pointers @baywet, I will give it a try.

[andreaTP]

Just skimmed through, but, if I understand this correctly, this is done in Java:

kiota/src/Kiota.Builder/Writers/Java/CodeEnumWriter.cs

Line 28 in e155222

writer.WriteLine($"{enumOption.Name.ToFirstCharacterUpperCase()}(\"{enumOption.SerializationName}\"){(enumOption == lastEnumOption ? ";" : ",")}");

and the desired encoding for C# looks pretty much matching the current Java encoding.

[vadrsa]

@baywet I created a new pr with a small fix for my last pr, #2494

[baywet]

I can see you forked the naming convention aspect into #2495, so we'll keep this issue just for the enum member aspect in dotnet.