Enum values are documented according to naming strategy

[JoachimL]

We are having some issues with how our enum values are documented by this extension.
The root cause is this function, which (regardless of DisplayAttributes, etc) always ends up lowercasing the first letter of the enum values. (We do use StringEnumConverter).

    public static string ToDisplayName(this MemberInfo element, NamingStrategy namingStrategy = null)
    {
        element.ThrowIfNullOrDefault();

        if (namingStrategy.IsNullOrDefault())
        {
            namingStrategy = new DefaultNamingStrategy();
        }

        var displayAttribute = element.GetCustomAttribute<DisplayAttribute>(inherit: false);
        var enumMemberAttribute = element.GetCustomAttribute<EnumMemberAttribute>(inherit: false);

        // EnumMemberAttribute takes precedence to DisplayAttribute
        var name = !enumMemberAttribute.IsNullOrDefault()
                   ? enumMemberAttribute.Value
                   : (!displayAttribute.IsNullOrDefault()
                      ? displayAttribute.Name
                      : element.Name);

        return namingStrategy.GetPropertyName(name, hasSpecifiedName: false);
    }

A very simple example is this:

[JsonConverter(typeof(StringEnumConverter))]
public enum Animal
{
    Dog,
    Cat,
    Elephant
}

The stringenumconverter will make sure that any model containing an Animal property will be formatted to string, but the naming strategy (which is hard coded to CamelCaseNamingStrategy in OpenApiHttpTriggerContext.cs) will force it to be camelCased when it's documented, which is obviously rather misleading.

In case it's not clear from my description, this is how it works in practice:
We have an API returning a model containing an Animal value. The open api docs show this:

If the API is called, this is what's returned:

Notice that the docs say that the Animal enum contains camelCased values, while the actual returned model is PascalCased.

This behavior is documented at https://github.com/healthfitnessnordic/azure-functions-openapi-extension/tree/feature/enum-names

In my opinion, the contents of a model should not be altered by the documentation, and enum values are arguably content. In addition, if I add a Display attribute/enum member attribute, I would expect the contents of those attributes to be respected without being altered in any way.

I've added a PR with my proposed fixes/changes at #171

[fredriklrsn]

I have also had the same issue with the open api documentation handling the enum values different than the function api serializer, which leads to mismatch between documented and returned values.

[joostvanhassel]

This seems to be a duplicate of #103 which was solved in #159

[JoachimL]

Confirmed - this is a duplicate.