ConfigurationBinder.Get binds empty IDictionary<string, string> as null

[realbart]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When serializing options, I expect an empty JSON-object { } to be serialized to an empty Dictionary.

Expected Behavior

When reading an options-object using configuration.GetSection("Foo").Get<FooOptions>(); I expect a dictionary to be empty not null.

Steps To Reproduce

1. Create a configuration

{
    "Foo" : {
        "Bar": 1,
        "Baz": {
        }
    }  
}

2. Create an OPTIONS object

public record FooOptions
{
    public required int Bar { get; init; }
    public required IDictionary<string, string> Baz{ get; init; }
}

3. Read it!

public void ConfigureServices(IConfiguration configuration, IServiceCollection services, TokenCredential credential)
{
    var fooOptions = configuration.GetSection("Foo").Get<FooOptions>();
    foreach ((var key, var value) in Baz) {
       // do something
    }
}

Expected behavior:

fooOptions.Baz is an empty dictionary, which can be enumerated

Actual behavior:

fooOptions.Baz is null

Exceptions (if any)

No response

.NET Version

8.0.301

Anything else?

This behavior occurs in a ASP.NET 8 project

[realbart]

Workaround:

public record FooOptions
{
    public required int Bar { get; init; }
    public IDictionary<string, string> Baz{ get; init; } = new Dictionary<string, string>();
}

[martincostello]

Looks like this issue should be transferred to dotnet/runtime as it doesn't appear to be specific to ASP.NET Core.

[tarekgh]

This looks like the current behavior is still acceptable. Think about it why creating objects which do not have any configuration values?

Currently the configuration only has values and treats the empty nested configuration {} as if it does not exist. There is an easy workaround for that which makes the property getter create the dictionary if it is null. Would that work for your case?

[realbart]

I've just pointed out inconsistent and unexpected behavior.
Not creating the object has little advantages because either the workaround creates this object or null checks are needed.
(Actually, this workaround always creates an empty dictionary which may or may not be overwritten)
And you need to remember to use a nullable IDicitonary<> instead of a regular one.
But if nobody else has a problem with this, I am not going to force the issue.

[tarekgh]

Thanks @realbart for your response. I am closing the issue for now and watch if we get more demand, we can consider doing something with this issue.