Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions docs/core/extensions/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,11 +73,13 @@ One of the key advantages of using the .NET configuration abstractions is the ab

These abstractions are agnostic to their underlying configuration provider (<xref:Microsoft.Extensions.Configuration.IConfigurationProvider>). In other words, you can use an `IConfiguration` instance to access any configuration value from multiple providers.

The binder can use different approaches to process configuration values:​
The binder can process configuration values in several ways:

- Direct deserialization (using built-in converters) for primitive types​.
- The <xref:System.ComponentModel.TypeConverter> for a complex type when the type has one​.
- Reflection for a complex type that has properties.
- Use a single configuration value directly for a `string` or `object` target, or convert it to a common .NET type, such as a numeric type, an enumeration, or a nullable type. The binder converts a Base64-encoded string to a byte array.
- Bind hierarchical configuration to an object's properties or constructor parameters.
- Bind child configuration sections to arrays, collections, sets, and dictionaries.
- Use the matching configuration section directly when the target type is <xref:Microsoft.Extensions.Configuration.IConfigurationSection>.
- Convert a single configuration value to a custom type. The default binder uses a <xref:System.ComponentModel.TypeConverter> when the custom type defines one. The source generator binder doesn't support this.
Comment on lines +78 to +82

> [!NOTE]
> The binder has a few limitations:
Expand Down
Loading