Implement proper parsing of primitives in config binder generator

[layomia]

from @eerhardt in #82179 (comment) (fyi @stephentoub)

A couple things here:

Parsing:

1. In order to be consistent with the reflection based behavior, we need to catch the int.Parse exception thrown here, and wrap it in a InvalidOperationException and add the configuration path of the invalid data. This allows devs to easily know where the invalid data exists from the exception message.
2. This should be int.Parse(valueString, NumberStyles.Integer, NumberFormatInfo.InvariantInfo);

See the following for how I did it when manually writing the bind code for Console Logging:

runtime/src/libraries/Microsoft.Extensions.Logging.Console/src/ConsoleLoggerOptions.cs

Lines 222 to 239 in 967250c

	internal static bool ParseInt(IConfiguration configuration, string key, out int value)
	{
	if (configuration[key] is string valueString)
	{
	try
	{
	value = int.Parse(valueString, NumberStyles.Integer, NumberFormatInfo.InvariantInfo);
	return true;
	}
	catch (Exception e)
	{
	ThrowInvalidConfigurationException(configuration, key, typeof(int), e);
	}
	}
	value = default;
	return false;
	}

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

from @eerhardt in #82179 (comment) (fyi @stephentoub)

A couple things here:

Parsing:

1. In order to be consistent with the reflection based behavior, we need to catch the int.Parse exception thrown here, and wrap it in a InvalidOperationException and add the configuration path of the invalid data. This allows devs to easily know where the invalid data exists from the exception message.
2. This should be int.Parse(valueString, NumberStyles.Integer, NumberFormatInfo.InvariantInfo);

See the following for how I did it when manually writing the bind code for Console Logging:

runtime/src/libraries/Microsoft.Extensions.Logging.Console/src/ConsoleLoggerOptions.cs

Lines 222 to 239 in 967250c

	internal static bool ParseInt(IConfiguration configuration, string key, out int value)
	{
	if (configuration[key] is string valueString)
	{
	try
	{
	value = int.Parse(valueString, NumberStyles.Integer, NumberFormatInfo.InvariantInfo);
	return true;
	}
	catch (Exception e)
	{
	ThrowInvalidConfigurationException(configuration, key, typeof(int), e);
	}
	}
	value = default;
	return false;
	}

Author:	layomia
Assignees:	layomia
Labels:	area-Extensions-Configuration, source-generator
Milestone:	8.0.0

[ericstj]

If we decide to directly use converters we should measure the size impact -- maybe directly referencing a converter is less expensive then GetCoverter (which I think @eerhardt said is huge), but it still looks pretty big. Maybe we can just look to the converters for inspiration of which parse/tryparse signatures to call, then generate those?

[tarekgh]

I think the idea is not using the converters at all and just having the parse code embedded inside the generated code. no dependency and not calling type converter.

[eerhardt]

For built-in types like int, bool, and enum, I don't see a benefit pulling TypeConverter into the app. Using the parsing logic directly makes sense to me.

See also #44493 (comment) about TypeConverter extensibility being opt-in.

The one use of config binding in Console Logging shouldn't pull in TypeConverter at all. See #81931 for why and numbers.

[layomia]

I think the idea is not using the converters at all and just having the parse code embedded inside the generated code. no dependency and not calling type converter.

Yeah this is what I meant.

[eerhardt]

One option for the "opt in" model of TypeConverters is to respect the TypeConverterAttribute if either:

• Directly applied to the property
• Directly applied to the Type of the property

So, for example:

[TypeConverter(typeof(PointConverter))]
public struct Point
{
   public int X;
   public int Y;
}

public class CustomOptions
{
    public Point CurrentPoint { get; set }
}

or

public struct Point
{
   public int X;
   public int Y;
}

public class CustomOptions
{
    [TypeConverter(typeof(PointConverter))]
    public Point CurrentPoint { get; set }
}

See also:

• Developers can safely trim apps which need Configuration Binder #44493 (comment)
• Support TypeConverterAttribute on bound properties #36545

[layomia]

@eerhardt I opened #83599 to discuss this.