Enums are not case insensitive

[vmelamed]

First off: great job, guys!

Small issue: it looks like even though the wiki states that option properties bound to enum values are case insensitive:

When specifying enum values, you don't need to respect case. Both app -g bye and app --greet-type REGARDS are allowed.

unfortunately, they are not. I have a program that for a line like this:

settings -s gogo -v 23 -t int

where -t is bound to an enum SettingType {Int, String, ...}, I get an error:

ERROR(S):
  Option 't, type' is defined with a bad format.

  -s, --setting      The name of a setting to be added or modified.

  -v, --value        The new value of the setting. The option is required if -s or --setting is specified.

  -t, --type         (Default: String) The case-sensitive type of the value of the setting. The option is not mandatory and if not specified, the
                     type will be either implied from the existing setting with the same name or it will be assumed to be 'String'. The most common
                     types are: String, Int, Guid, Decimal, Boolean, DateTime, Date, Time, Uri, TimeSpan. DateTime values are assumed to be UTC.

[...etc]

BadFormatConversionError
  StopsProcessing          = False
  Tag                      = ErrorType.BadFormatConversionError
  NameInfo                 = NameInfo
    LongName                 = type
    NameText                 = t, type
    ShortName                = t

But if I enter the command like this:

settings -s gogo -v 23 -t Int

all is good.

[nemec]

If you configure your own parser settings you can set CaseInsensitiveEnumValues to true - does that solve your problem?

var parser = new Parser(with => with.CaseInsensitiveEnumValues = true);

[vmelamed]

This didn't seem to have any effect. Maybe I'm doing it wrong but...

[mscrivo]

Same issue here, CaseInsensitiveEnumValues has no effect

[harlam357]

Also experiencing the same issue using the latest v2.2.0 package. Setting CaseInsensitiveEnumValues = true has no effect.

[mdesousa]

Also, I just upgraded from version 1.9.71 where CaseInsensitiveEnumValues used to be true by default. It appears that the new version (2.2.1) changes the default to be false... is this intentional? I think it would be more convenient to continue having the same default behavior as before.

[mleenhardt]

I'm running into the same issue, any chance the fix in #231 could be merged?

[Sergio0694]

Same here with version 2.2.1, the CaseInsensitiveEnumValues option doesn't work.
Looking forward to the next update with the fix 😊

[nemec]

Can you provide a code sample that isn't working for you? I just tested the following in 2.2.1 and the case insensitive setting works as advertised.

void Main()
{
	var parser = new Parser(cfg => cfg.CaseInsensitiveEnumValues = true);
	var results = parser.ParseArguments<Options>("-t two".Split())
		.WithParsed<Options>(opts => opts.Dump())
		.WithNotParsed<Options>((errs) => { });
}

public class Options
{
	[Option('t', "test")]
	public Test Test { get; set; }
}

public enum Test
{
	One,
	TWO
}

[Sergio0694]

@nemec Hello, thank you for your answer. I can confirm that the issue is still present, and that it is only happening when using the ParseArguments<T1, T2, …>() overload. Using the method with a single type parameter works fine for me, both using an option and using a verb.

Consider this example:

public enum SomeEnum
{
    Hello,
    World
}

public class SomeOptions
{
    [Option('f')]
    public SomeEnum Foo { get; set; }
}

[Verb("verb")]
public class SomeVerb : SomeOptions { }

[Verb("otherverb")]
public class SomeOtherVerb : SomeOptions { }

The following snippet fails with a "BadFormatConversionError" error:

var test = new[] { "verb", "-f", "world" };
var parser = new Parser(settings => settings.CaseInsensitiveEnumValues = true);
var result = parser.ParseArguments<SomeVerb, SomeOtherVerb>(test);

Hope this helps! 😄

[masters3d]

Having the same issue as @Sergio0694 . I think the default should be set to true.

[giuliov]

It would be nice if you merge this PR after so many months.

[o4zloiroman]

Yeah, it's still not explained on wiki that the default value for this setting is actually false.