Configuration binder source generator emits unqualified List<T> when binding arrays without implicit usings
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- csharp
- Domain
- backend, build-system
Research direction
Start with gen/Emitter/CoreBindingHelpers.cs, especially EmitBindCoreImplForArray, which the issue identifies as emitting the unqualified List<T>. Build the provided reproduction with implicit usings disabled, then inspect the generated BindingExtensions.g.cs to confirm the failure. Done means array binding compiles without global using directives; also investigate why testing of #121364 missed this case.
Written by the indexing model from the issue text.
Description
Description
The configuration binder source generator produces code that fails to compile when binding an array with implicit usings disabled.
This is a remaining case of #118630: #121364 qualified the generated HashSet<> references, but the temporary List<> used for array binding remains unqualified.
Reproduction Steps
Create these two files and run dotnet build.
repro.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net11.0</TargetFramework>
<ImplicitUsings>disable</ImplicitUsings>
<EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Configuration.Binder"
Version="11.0.0-rc.3.26522.148" />
</ItemGroup>
</Project>
Program.cs
using Microsoft.Extensions.Configuration;
new ConfigurationBuilder().Build().Get<int[]>();
Expected behavior
The generated code compiles without requiring global using directives from the consuming project.
Actual behavior
The build fails:
BindingExtensions.g.cs(66,29): error CS0246: The type or namespace name 'List<>' could not be found (are you missing a using directive or an assembly reference?)
The generated array-binding method contains:
var temp1 = new List<int>();
The generated file neither imports System.Collections.Generic nor fully qualifies this type.
Regression?
Not a new .NET 11 regression. The original example also fails with Binder 8.0.0, 9.0.0, and 10.0.14, where the unqualified HashSet<> reference causes a compilation error first. The .NET 11 fix removes that error but leaves this array-binding failure.
Known Workarounds
Enable implicit usings, or add:
global using System.Collections.Generic;
Other information
EmitBindCoreImplForArray in gen/Emitter/CoreBindingHelpers.cs emits new List<...>() directly. Fully qualifying that reference would address this case.
When investigating this, also consider looking into why testing of #121364 didn't find this issue.
[!NOTE]
This issue was drafted with GitHub Copilot assistance.
- Dominant language
- C#
- Stars
- 18.4k
- Forks
- 5.8k
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 596
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/runtime
-
area-Extensions-FileSystem untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
dotnet/runtime#136989 · 1 comment ·
Maintainers usually reply within 1 day
-
[wasi] .NET 10: WasmEnableSIMD with AOT fails because WasiApp.targets has -msimd128 commented outOpenarea-Build-mono untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area-System.ComponentModel untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
dotnet/runtime#136608 · 2 comments ·
Maintainers usually reply within 1 day
-
MemoryMappedFile (Windows): failed MEM_COMMIT is ignored, accessor over reserved memory crashes the processPossibly taken @RutulPatel8 claimed this 3 days ago. Openarea-System.IO bug untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
dotnet/runtime#136599 · 1 comment ·
Maintainers usually reply within 1 day
-
area-System.IO untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
dotnet/runtime#136577 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
要トリアージ
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
S: Untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Trauma-Station/Trauma-Station#5285 ·
Maintainers usually reply within 1 day
-
.NET good first issue testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
HelloblueAI/HelloblueGK#311 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
unoplatform/uno#26080 ·
Maintainers usually reply within 1 day
-
area:app
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
KSAModding/Borea#1162 · 1 comment ·
Maintainers usually reply within 1 day