Support IConfiguration as a bindable property type in options classes

[Copilot]

Summary

This PR adds support for binding IConfiguration properties in ConfigurationBinder and the configuration binding source generator, fixing #42035.

The original discussion claimed that handling IConfigurationSection is sufficient. But that didn't consider that users naturally expect IConfiguration-typed properties to work as well — they do not know that using IConfigurationSection specifically is necessary, and the silent failure is confusing.

Changes

src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs

• Extended the early-exit check in BindInstance to also short-circuit when binding IConfiguration (not just IConfigurationSection). The config object is assigned directly to the binding point.

Source generator (gen/)

• Added IsIConfiguration property to ConfigurationSectionSpec to distinguish between IConfiguration and IConfigurationSection specs.
• In the parser, added a new branch to produce a ConfigurationSectionSpec { IsIConfiguration = true } when the type is IConfiguration.
• In the emitter, added a new case for ConfigurationSectionSpec { IsIConfiguration: true } that emits return configuration; directly, without the cast-to-IConfigurationSection guard.
• Renamed the local EmitCastToIConfigurationSection helper to EmitCastToIConfigurationSectionOrThrow to better reflect its behavior.

Tests (tests/Common/)

The diff of tests is a bit confusing, mostly because of the move of CanBindIConfigurationSectionWithDerivedOptionsSection to a better location in the file.

• Renamed ConfigurationInterfaceOptions to OptionsWithIConfigurationSection for clarity.

• Added OptionsWithIConfiguration and DerivedOptionsWithIConfiguration test classes.

• Added CanBindIConfiguration test verifying that properties of type IConfiguration are bound correctly (including via all Get<T> overloads).

• Added CanBindIConfigurationWithDerivedOptionsSection test verifying nested binding through IConfiguration properties.

• Moved the existing CanBindIConfigurationSectionWithDerivedOptionsSection test.

• Added GetIConfiguration test verifying Get<IConfiguration>(), Get<List<IConfiguration>>(), and Get<Dictionary<string, List<IConfiguration>>>() all work correctly.

• Fixes IConfiguration type binding for properties in Options pattern. #42035

Original prompt

---

This section details on the original issue you should resolve

<issue_title>IConfiguration type binding for properties in Options pattern.</issue_title>
<issue_description>Hello everybody,

I defined the following configuration option class for use with Options pattern:

public class RouteOptions
{
   public string Name { get; set; }
   public string Local { get; set; }
   public string Remote { get; set; }
   public string HttpClientName { get; set; }
   . . .
   public IConfiguration Extra { get; set; }
}

The "Extra" field by my design would include various extra settings that will be accessed by business logic located outside of my code, e.g. plugins written by other developers. I was expecting this to work, but to my surprise, this property is never assigned.

Probably it is very easy to bind this field it does not require any conversion, just assign GetSection("propertyName") to the property.

Is it possible to introduce this functionality?

I think it is essential.

With best regards,
Arman</issue_description>

<agent_instructions>In the PR description, mention that the benefit that aspnet/Configuration#353 (comment) was missing is that users expect this to work and don't know that using IConfigurationSection is necessary.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@Dotnet-GitSync-Bot I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one [area label](https://github.com/dotnet/runtime/blob/master/docs/area-owners.md). @ Tagging subscribers to this area: @maryamariyan See info in area-owners.md if you want to be subscribed. @rosebyte Triage: we can investigate why IConfiguration isn't supported now and consider support it.

[Copilot]

Pull request overview

Adds first-class support for binding IConfiguration-typed properties in ConfigurationBinder (and its source generator), addressing the surprising “silent no-op” behavior when options classes include IConfiguration properties.

Changes:

• Extend ConfigurationBinder.BindInstance to short-circuit for IConfiguration (similar to IConfigurationSection).
• Update the binding source generator to model/emit IConfiguration vs IConfigurationSection correctly.
• Add/adjust tests validating binding behavior for IConfiguration properties and Get<T>() scenarios.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.cs	Adds/reshuffles tests for IConfiguration binding and Get<IConfiguration>() container scenarios.
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.TestClasses.cs	Introduces new options/test classes for IConfiguration and renames existing section-focused option type.
src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs	Extends early-exit binding logic to directly bind IConfiguration.
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/Specs/Types/SimpleTypeSpec.cs	Adds a discriminator (IsIConfiguration) to distinguish spec flavor in generator pipeline.
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/Emitter/CoreBindingHelpers.cs	Emits direct-return for IConfiguration and keeps cast/throw behavior for IConfigurationSection.
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/ConfigurationBindingGenerator.Parser.cs	Produces the new IsIConfiguration spec variant when parsing IConfiguration properties.

[svick]

After a discussion with the team, I'm closing this. While using IConfiguration this way makes logical sense, that interface is also sometimes used to represent the whole configuration (e.g. in DI), so it could be confusing. IConfigurationSection is a perfect fit and already works, so nothing needs to be changed.