Fix config binding source generator duplicating collection items bound through a constructor parameter

[svick]

Summary

Fixes #83803.

The Configuration Binding source generator duplicated the items of a collection property that is populated through a matching constructor parameter. For example, given:

internal sealed class Source(string Name, IEnumerable<string> Addresses, IList<int> Ints, string[] Strings)
{
    public string Name { get; } = Name;
    public IEnumerable<string> Addresses { get; } = Addresses;
    public IList<int> Ints { get; } = Ints;
    public string[] Strings { get; } = Strings;
}

binding ints: [1, 2, 3, 4, 5] produced 1, 2, 3, 4, 5, 1, 2, 3, 4, 5. Arrays and scalars were unaffected; only additive collections (IList<T>, IEnumerable<T>, settable collections) duplicated. The reflection binder was already fixed (#106158, #129775); this brings the source generator in line.

Root cause

For a type with a parameterized constructor, the generated code first calls Initialize(...) — which invokes the constructor, binding each constructor parameter into its collection — and then calls BindCore(...), which re-bound every property. Re-binding a collection property appends to the collection the constructor already filled, so the items appear twice.

Fix

The generated BindCore method now takes an optional boundThroughConstructor parameter, emitted only for parameterized-constructor object types that actually have a re-bindable constructor-matched property. Constructor-matched properties are deferred into an if (!boundThroughConstructor) block, so they are bound only when the instance was not created through its constructor (e.g. config.Bind(existingInstance)), matching the reflection binder's BindProperties/ResetPropertyValue behavior.

Call sites pass the flag when the instance is (re)created:

• true for unconditional construction (var x = Initialize(...)),
• a runtime wasNull flag for the x ??= Initialize(...) case, since the constructor only runs when the existing value was null.

No baseline .generated.txt changes: the extra parameter/guard only appear for the affected type shapes, none of which are in the baseline suite.

Known limitation

A settable scalar that is both a constructor parameter and has an observable side-effecting setter has its setter invoked once here vs. twice by the reflection binder (which resets it to its current value). This is untested/pathological, and the previous source-gen behavior already diverged there too. Collections, init/required properties, and normal setters all match the reflection binder exactly.

Note

This pull request was authored with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the Microsoft.Extensions.Configuration.Binder source generator to avoid re-binding constructor-matched collection properties (which can cause additive collections to duplicate items) by adding a boundThroughConstructor flag to generated BindCore overloads and guarding the relevant property-binding paths. Tests are updated to validate the behavior in both reflection and source-gen modes.

Changes:

• Extend generated BindCore methods (for affected parameterized-constructor object shapes) with an optional boundThroughConstructor parameter and skip re-binding ctor-matched properties when it’s true.
• Update the emitter call sites to pass boundThroughConstructor: true when an instance is freshly constructed, and a runtime wasNull flag for ??= initialization patterns.
• Update binder tests: remove the SourceGen-mode ActiveIssue gate for the case-mismatched ctor-parameter scenario and add coverage for same-cased ctor-parameter collection binding.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.TestClasses.cs	Adds a new test class with ctor-matched collection parameters/properties for same-cased repro coverage.
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.cs	Un-gates an existing test for source-gen mode and adds a new regression test for same-cased ctor parameter/property collection binding.
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/Emitter/Helpers.cs	Adds identifier constants used by the emitter (boundThroughConstructor, wasNull).
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/Emitter/CoreBindingHelpers.cs	Implements the boundThroughConstructor parameter, defers ctor-matched properties behind a guard, and updates key call sites to pass the flag on construction.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[tarekgh]

Looks good. One suggestion on test coverage: the added tests cover the top-level Get<T>() path and the dictionary path, but not the nested-property ??= path, which is where boundThroughConstructor is computed at runtime (wasNull) rather than being a constant.

Worth adding (true regression test): a container whose property type has a ctor-matched collection, bound via a nested null property. This exercises the wasNull branch and would duplicate on the unfixed source generator.

public sealed class ContainerWithCtorCollectionChild
{
    public GetterOnlyInterfaceCollectionWithCaseMismatchedCtorParameter Child { get; set; }
}

[Fact]
public void CanBind_NestedTypeWithCollectionConstructorParameter()
{
    string json = """
    {
        "Child": { "Instances": [ "a", "b" ] }
    }
    """;

    IConfiguration config = TestHelpers.GetConfigurationFromJsonString(json);
    var result = config.Get<ContainerWithCtorCollectionChild>();

    Assert.Equal(new[] { "a", "b" }, result.Child.Instances);
}

Without the fix this produces ["a","b","a","b"]; with it, ["a","b"]. It also runs under both binders since it lives in tests/Common.

Nice to have (guard, not a repro): a Bind(existingInstance) case for a settable ctor-matched collection. This one passes with or without the change, so it does not catch the current bug, but it locks in the boundThroughConstructor: false branch so a future change cannot start over-skipping and silently stop binding those properties.

[Fact]
public void CanBindExistingInstance_BindsCtorMatchedCollection()
{
    string json = """
    {
        "Instances": [ "first", "second" ]
    }
    """;

    IConfiguration config = TestHelpers.GetConfigurationFromJsonString(json);
    var instance = new SettableCollectionWithCaseMismatchedCtorParameter(new List<string>());
    config.Bind(instance);

    Assert.Equal(new[] { "first", "second" }, instance.Instances);
}