Fix config binder source gen for a sole read-only collection ctor param by TemRevil · Pull Request #131358 · dotnet/runtime

TemRevil · Jul 25, 2026

The configuration binder source generator emitted an uncompilable call to an Initialize method that was never generated, for a parameterized-constructor type whose only member is a non-bindable copy-constructor collection parameter (a positional record with a single IReadOnlyList, IReadOnlyCollection, IReadOnlySet, or IEnumerable parameter and no other bindable property). The reflection binder handles this shape correctly, so this was a parity regression that broke the build instead.

Root cause: BindingHelperInfo.Builder.TryRegisterTransitiveTypesForMethodGen only registered a type for Initialize-method generation inside the HasBindableMembers(objectSpec) check. But constructor parameters are bound in Initialize independently of whether the type has any other bindable property, per the comment already on the ctor-param property loop a few lines above. For a type where the only "property" is a ctor param backed by a non-bindable read-only collection type, HasBindableMembers is false, so Initialize never got registered/emitted, while the emitter's EmitBindingLogic/EmitObjectInit still unconditionally calls InitializeXxx(...) for any ParameterizedConstructor type.

Fix: register the Initialize method (and walk the constructor-parameter properties needed to bind it) whenever the type has a parameterized constructor, regardless of HasBindableMembers. BindCore registration stays gated on HasBindableMembers as before, since that part is unrelated.

Verified by running the incremental generator directly against the repro from the issue:

var config = new ConfigurationBuilder().Build();
Options options = config.Get<Options>();
public record Options(IReadOnlyList<string> Values);

Before this change the generated source calls InitializeOptions but never defines it, reproducing CS0103: The name 'InitializeOptions' does not exist in the current context exactly. After this change the method is generated and binds the parameter correctly. Confirmed for all four affected collection interfaces (IReadOnlyList, IReadOnlyCollection, IReadOnlySet, IEnumerable).

Added SoleReadOnlyCollectionConstructorParameterIsBindable next to the existing ReadOnlyCollectionConstructorParameterIsBindable test, covering the case where the collection parameter is the type's only member (the existing test always paired it with a second, ordinarily-bindable property, so it didn't exercise this gap).

The configuration binder source generator emitted a call to an Initialize method that was never generated for a parameterized- constructor type whose only member is a non-bindable copy-constructor collection parameter (IReadOnlyList<T>, IReadOnlyCollection<T>, IReadOnlySet<T>, or IEnumerable<T>, with no other bindable property). The reflection binder already handled this shape correctly, so this was a parity gap that broke the build with CS0103 instead. The registration pass only registered a type for Initialize-method generation inside the HasBindableMembers check, but constructor parameters are bound in Initialize independently of whether the type has any other bindable property. Register the Initialize method (and walk the constructor-parameter properties needed to bind it) whenever the type has a parameterized constructor, regardless of HasBindableMembers. Verified by running the incremental generator directly against the repro from the issue (record with a single IReadOnlyList<string> constructor parameter): before this change the generated source calls InitializeOptions but never defines it, reproducing CS0103 exactly; after this change the method is generated and binds the parameter correctly. Confirmed for all four affected collection interfaces. Fixes dotnet#131320

azure-pipelines · Jul 25, 2026

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.

dotnet-policy-service · Jul 25, 2026

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

tarekgh

A few test-hardening notes on the new regression test. The product change itself looks correct and well targeted; these are non-blocking suggestions. One additional stylistic thought: the sibling ReadOnlyCollectionConstructorParameterIsBindable, ComplexReadOnlyListConstructorParameterIsBindable, and this new Sole... test all cover variations of the same shape, so they could eventually be consolidated into a single data-driven theory.

tarekgh · Jul 25, 2026

+            Assert.NotNull(result.GeneratedSource);
+            Assert.Empty(result.Diagnostics);
+
+            AssertCanCreateAssemblyImage(result.OutputCompilation);


The assertions stop at compile-clean plus a produced assembly image. Since this fixes a source generator vs reflection parity regression, consider also asserting runtime binding behavior: populate an in-memory configuration with a value for Values, call Get<Options>(), and assert the resulting collection contents. A generator can emit compilable but functionally wrong binding, and only a functional assertion guards against that.

Reopening: this new functional assertion is failing in CI across 7 configurations (osx/linux/alpine/windows) in the current run.

System.IO.FileLoadException : Could not load file or assembly 'test.dll'. A different copy of assembly 'test.dll' is already loaded. at ...LoadAndInvokeMain(...) GeneratorTests.Helpers.cs:line 244 at ...SoleReadOnlyCollectionConstructorParameterIsBindable(String collectionType) GeneratorTests.cs:line 586

Root cause: LoadAndInvokeMain loads the compiled image into AssemblyLoadContext.Default, and every theory case compiles an assembly with the same simple name test. The first InlineData case loads fine; each subsequent case collides with the already-loaded identity and throws. The new complex-element test will hit the same problem when it runs in the same process.

Two ways to fix:

Give each compilation a unique assembly name (for example derive it from collectionType or a GUID) so the identities do not collide. This is the smaller change and matches how these tests otherwise isolate compilations.

Load each image into a fresh collectible AssemblyLoadContext per invocation instead of Default.

Please apply one of these and confirm the theory actually runs green in CI (check the test count in the log).

tarekgh · Jul 25, 2026

+                    }
+                }
+
+                public record Options({{collectionType}}<string> Values);


Two coverage gaps around this shape:

Sole member plus complex element type is not exercised. The existing ComplexReadOnlyListConstructorParameterIsBindable pairs the collection with a bindable Name (so HasBindableMembers is true, the old path). Here the element is string. The intersection, for example record Options(IReadOnlyList<Child> Values) with no other member, is what newly drives the property walk transitive registration and RegisterForGen_AsConfigWithChildrenHelper in the changed code path, and it is untested.

Nested usage is not exercised. Reaching this type as a member of an outer bound type goes through BindCore and EmitObjectInit rather than top level GetCore, which is a distinct emission path. It very likely works, but a nested case would lock it in.

… fix Compiling proved the Initialize method gets emitted, but never asserted the generated code binds the right values. Extend the existing theory to populate real config and check the bound collection contents for all four interface shapes (including IEnumerable, which still routes through the same CopyConstructor/HasBindableMembers=false path as the others). Add a sibling test for a complex (non-string) element type, the other gap called out in review.

TemRevil · Jul 25, 2026

Added functional coverage for both gaps, pushed as 16c022b5. SoleReadOnlyCollectionConstructorParameterIsBindable now populates real config, invokes the compiled assembly, and asserts the bound collection contents for all four interface shapes. Added a sibling test, SoleReadOnlyCollectionConstructorParameterOfComplexElementIsBindable, for the complex-element case: record Options(IReadOnlyList<Child> Values) with no other member. The existing ComplexReadOnlyListConstructorParameterIsBindable always pairs the collection with a bindable Name, so it never actually hit this code path.

On whether IEnumerable<string> exercises the fix: it does. I reverted to the parent commit and ran all four shapes through the generator directly. Pre-fix, IEnumerable<string> fails with the identical CS0103: The name 'InitializeOptions' does not exist as the other three, since it also resolves to CollectionInstantiationStrategy.CopyConstructor in the parser (same as IReadOnlyList/IReadOnlyCollection/IReadOnlySet), so IsCollectionAndCannotOverride excludes it from HasBindableMembers the same way. Post-fix, all four compile and bind correctly.

The nested case turned up something real, though not what either of us expected. Binding Outer.Nested (an Inner whose sole member is a read-only collection ctor param) silently produces null instead of the actual value, no exception. Traced it to CoreBindingHelpers.cs's EmitBindImplForMember, the early return around line 961: !HasBindableMembers(complexType) && ... && InstantiationStrategy == ParameterizedConstructor skips emitting the property assignment entirely, even though InitializeInner is generated correctly and CanInstantiate is true for that exact type. git diff confirms that block is untouched by this PR, present verbatim at the parent commit too, so it's a pre-existing gap in the nested/BindCore path rather than something this fix introduced.

Since it's a different root cause in a different file, I didn't fold a fix into this PR without checking first. Happy to open a follow-up issue with the repro, take a shot at fixing it separately, or fold it into this PR if you'd rather keep it together, whichever you prefer.

tarekgh · Jul 26, 2026

Thanks for the thorough follow-up.

The functional assertions and the complex-element sole-member test look good, and confirming that IEnumerable<string> hits the same pre-fix failure and now exercises the fixed path resolves my earlier concern. Including all four interface shapes as theory cases is exactly what I was after.

On the nested-usage gap: since the null-binding you found for Outer.Nested is a separate, pre-existing bug that this PR does not touch, let us not fold a fix into this one. Please open a dedicated issue with the minimal repro (the record Options(IReadOnlyList<Child> Values) nested under an outer type) and reference it here so we can track it independently. This PR can merge on its own once the nested case is captured in that issue.

Two small things before I sign off:

Can you add a short code comment (or test comment) noting that nested binding of these read-only collection members is tracked separately, so the gap is discoverable from the test file?
Please make sure the new theory cases are actually running in CI (check the test count in the log), since source-gen tests can silently skip if the baseline is not built.

github-actions Bot added the area-Extensions-Configuration label Jul 25, 2026

dotnet-policy-service Bot added the community-contribution Indicates that the PR has been added by a community member label Jul 25, 2026

tarekgh reviewed Jul 25, 2026

View reviewed changes

build-analysis Bot mentioned this pull request Jul 25, 2026

System.Net.Sockets.Tests tests fail with ObjectDisposedException #126183

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix config binder source gen for a sole read-only collection ctor param#131358

TemRevil commented Jul 25, 2026

Uh oh!

azure-pipelines Bot commented Jul 25, 2026

Uh oh!

dotnet-policy-service Bot commented Jul 25, 2026

Uh oh!

tarekgh left a comment

Uh oh!

tarekgh Jul 25, 2026

Uh oh!

tarekgh Jul 26, 2026

Uh oh!

tarekgh Jul 25, 2026

Uh oh!

Uh oh!

TemRevil commented Jul 25, 2026

Uh oh!

tarekgh commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Search code, repositories, users, issues, pull requests...

Uh oh!

Conversation

TemRevil commented Jul 25, 2026

Uh oh!

azure-pipelines Bot commented Jul 25, 2026

Uh oh!

dotnet-policy-service Bot commented Jul 25, 2026

Uh oh!

tarekgh left a comment

Choose a reason for hiding this comment

Uh oh!

tarekgh Jul 25, 2026

Choose a reason for hiding this comment

Uh oh!

tarekgh Jul 26, 2026

Choose a reason for hiding this comment

Uh oh!

tarekgh Jul 25, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TemRevil commented Jul 25, 2026

Uh oh!

tarekgh commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants