Custom binders for mapping config string values to types known to the composition root

[aejay]

The ease the Binding portion of this library adds to configuration is very valuable for the projects I'm involved in, but I find a lot of cases where the flexibility of binding seems to be lacking. I might just be approaching problems incorrectly (if so, any help pointing me in the right direction would be nice).

It seems like either the binder will work great because you are working with basic types that are easily bound, or the binder is useless because you need some custom logic, so you are left writing a bunch of manual steps to read out of Configuration (especially around Options).

I know the current Binder code uses the TypeDescriptor.GetConverter(Type type) method to attempt to do type conversion, but setting converters for types is a pain and doesn't cover all scenarios (e.g. there might be other information we need to get, such as from an IConfiguration, that is not available to us from the TypeConverter implementation). Relying on the TypeDescriptor method also relies heavily on ambient details that aren't always obvious at composition, and are not specific to a particular compositor. Those converters are part of the description of a type, not part of the composition of an application and its configuration/dependencies.

It would be nice if there were methods like this available:

public static IServiceCollection AddConfigurationBinder<T>(
    this IServiceCollection services, 
    Func<string, T> binderFunction)
{
    // Later when Bind() is called, ideally it would check for configured binders
    // before falling back to a default TypeConverter
}

This would allow us to do things like this:

appsettings.json

{
    "ConnectionStrings": {
        "SampleConnection": "[connection string goes here]"
    },
    "SomeLibrarySettings": {
        "ShouldDoAThing": true,
        "Connection": "SampleConnection"
    }
}

SomeLibraryOptions.cs

public class SomeLibraryOptions
{
    public bool ShouldDoAThing { get; set; }
	// As an example... directions for how reliant code should build out new connections
	public Func<IDbConnection> Connection { get; set; }
}

Startup.cs

public IConfiguration Configuration { get; }

public void ConfigureServices(IServiceCollection services)
{
    services.AddOptions();
    services.AddConfigurationBinder<Func<IDbConnection>>(configValue => {
        // When my options expects to bind a Func<IDbConnection>, use the string in the settings
        // to find the matching connection string and make a Func that builds a SqlConnection for it.
        var connectionString = Configuration.GetConnectionString(configValue);
        return () => new SqlConnection(connectionString);
    });

    services.Configure<SomeLibraryOptions>(Configuration.GetSection("SomeLibrarySettings"));
}

Does this make sense to do or are there other approaches that exist already (or are being worked on) that are better suited? I know this is a contrived example that would be solved by using the Action version of configure, but when we have common steps to perform on options again and again, I think it might be better to tell the ConfigurationBinder how to handle those type bindings generally vs individually.

[HaoK]

This is something we could consider adding to the new BinderOptions introduced with aspnet/Configuration#796

We could easily add a CustomBind<T>(Func<T> func) to the options, is that basically what you want for more control over a specific type?

   services.Configure<SomeLibraryOptions>(Configuration.GetSection("Settings", 
         o => o.CustomBind<IDbConnection>(() => new SqlConnection(Configuration.GetConnectionString(configValue));

Thoughts @ajcvickers @davidfowl

[andriysavin]

Here are more thoughts on the idea. I have almost the same scenario as @aejay decribes: I want to reference one section from another using section path, e.g.

{
"EmailSender" : {
   "FromEmail": "...",
   "ToEmails": "...",
   "SmtpServerSettingsReference" : "Accounts:Smtp"
},
"Accounts": {
 "Smtp" : {
      "ServerName": "...",
      "ServerPort": 587
}
}

}

Further, when I map "EmailSender" to a POCO object, I want the "SmtpServerSettingsReference" property in POCO to contain a POCO type, which will automatically be mapped from a referenced section.
However, for this particular scenario I would use other approach - a TypeConvertor, which would check the string in "SmtpServerSettingsReference" property if its a config path and would map the section at that path to the target type. But for this to be possible, the converter needs a reference to the whole IConfiguration. TypeConverter supports passing it some context via ITypeDescriptorContext , but its not used in the binder: (https://github.com/aspnet/Configuration/blob/release/2.0/src/Microsoft.Extensions.Configuration.Binder/ConfigurationBinder.cs#L471
So what I suggest is to provide TypeConverter with some configuration context to extend its abilities.

[andriysavin]

@HaoK What you suggest is a great idea and I think it should be implemented. However, sometimes (like in the case I described) you will want to configure such behaviour closer to configuration POCOs rather than to top level configuration code. For example, you may want to define a POCO or/and related POCOs with a type converter in a separate library, and have the library consumer to just use it. With your approach every application will require configuration code. Even if you put it into an extension method in the library, you will have to not forget to call it.

[NinoFloris]

@HaoK also important for F# users...

Most F# users usually use F# lists which are seen as non scalar by the binder. The binder then tries to access all properties of list, like Head which will result in an exception if you have a very normal default value, an empty list.

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.