Setting with empty value fails to convert to null-string

[dittodhole]

Giving following .ini-file and class:

[FOO]
SETTING=

public class FOO
{
  public string? SETTING { get; set; }
}

Reading the file with 3.2.9.1, which was written with 3.2.8, and mapping the Section object to an actual object with SetValuesTo(object) now fails with:

SharpConfig.SettingValueCastException: Failed to convert value '' to type System.String.
   at SharpConfig.Setting.CreateObjectFromString(String value, Type dstType, Boolean tryConvert)
   at SharpConfig.Setting.GetValue(Type type)
   at SharpConfig.Section.SetValuesTo(Object obj)
   at MY CODE ^^

There is no workaround available, since the default (false) for the tryConvert parameter of Setting.CreateObjectFromString is never overwritten!

[cemdervis]

Hi, I couldn't reproduce the exception; the object is constructed with SETTING's value being the empty string. Please verify in Setting.cs whether obj is the empty string or null.

[dittodhole]

Hi, and thanks for the prompt follow-up!

Mea culpa, I have a custom string-converter, which returns null rather than string.Empty which makes the following comparison fail.

I've updated the title accordingly.

[cemdervis]

Sure thing. So reading from the title, you expect the string conversion to return a null-string? Just to be clear. At this moment, an empty setting value will let the converter return an empty string respectively, because the conversion is valid. Only invalid conversions should return null.

[dittodhole]

I am not sure, whether I should expect this OOTB - but this is, where custom converters kick in :)

Naming a method TryXXX (as with the breaking change from 3.2.9 in ITypeStringConverter) should follow the best practice: indicate the success via a bool-return type (and the actual result via an out-parameter) rather than a magic value!

[cemdervis]

Yes, the naming is unfortunate. However, I won't drastically change the converter API until the next major release. So for the time being, we'd have to stick with the magic null values. Edit: is your converter able to return an empty string instead of a null-string? Or do you rely on null being returned?

[dittodhole]

Fair enough. I then have to wait for the next major release.

Thanks for your input!

PS: I am unable to change neither my custom converter nor my DTO, which is bolt on the behavior of 3.2.8, and uses the DTO for further processing, which would enforce a rewrite of the consecutive logic (or separating the bits out in a new DTO ...) - no worries, as I only wanted to upgrade for netstandard2.0 support.

[cemdervis]

I see. So you're able to work around this issue for now?

[dittodhole]

Yep, sticking to 3.2.8 ;)

[cemdervis]

Noted. Thanks for reporting these issues by the way.