Support immutable collections (System.Collections.Immutable) in options binding (ConfigurationBinder)

[ohadschn]

Related issue: dotnet/dotnet-api-docs#8658 (Possible threading issues with non thread safe collections in Options classes)

Consider the following app settings and corresponding options class:

// app.settings
{
    "MyStrings": ["a", "b", "c"]
}

public class MyOptions
{
    public ImmutableArray<string> MyStrings { get; set; }
   //or ImmutableHashSet<string>, or ImmutableDictionary<string,string>, etc.
}

Following a ConfigurationBinder.Bind call, the immutable array above is not bound (its IsDefault is true).
Indeed, this does not seem to be supported, where the closest thing I could find was read-only collection binding:

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/tests/ConfigurationCollectionBindingTests.cs

Line 1272 in 0f3a88b

public void CanBindUninitializedIReadOnlyCollection()

However, even assuming the client does not cast away the immutability, it's not as good as Immutable without any guarantee on the generated underlying type. This is specifically problematic when considering thread safety (which a readonly interface does not guarantee). Plus these is no ReadOnlySet<T> AFAIK (#29387).

[ghost]

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

Issue Details

---

Consider the following app settings and corresponding options class:

// app.settings
{
    "MyStrings": ["a", "b", "c"]
}

public class MyOptions
{
    public ImmutableArray<string> MyStrings { get; set; }
   //or ImmutableHashSet<string>, or ImmutableDictionary<string,string>, etc.
}

Following a ConfigurationBinder.Bind call, the immutable array above is not bound (its IsDefault is true).
Indeed, this does not seem to be supported, where the closest thing I could find was read-only collection binding:

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/tests/ConfigurationCollectionBindingTests.cs

Line 1272 in 0f3a88b

public void CanBindUninitializedIReadOnlyCollection()

However, even assuming the client does not cast away the immutability, it's not as good as Immutable without any guarantee on the generated underlying type. This is specifically problematic when considering thread safety (which a readonly interface does not guarantee). Plus these is no ReadOnlySet<T> AFAIK (#29387).

Author:	ohadschn
Assignees:	-
Labels:	area-System.Collections
Milestone:	-

[ghost]

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

Issue Details

---

Related issue: dotnet/dotnet-api-docs#8658 (Possible threading issues with non thread safe collections in Options classes)

Consider the following app settings and corresponding options class:

// app.settings
{
    "MyStrings": ["a", "b", "c"]
}

public class MyOptions
{
    public ImmutableArray<string> MyStrings { get; set; }
   //or ImmutableHashSet<string>, or ImmutableDictionary<string,string>, etc.
}

Following a ConfigurationBinder.Bind call, the immutable array above is not bound (its IsDefault is true).
Indeed, this does not seem to be supported, where the closest thing I could find was read-only collection binding:

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/tests/ConfigurationCollectionBindingTests.cs

Line 1272 in 0f3a88b

public void CanBindUninitializedIReadOnlyCollection()

However, even assuming the client does not cast away the immutability, it's not as good as Immutable without any guarantee on the generated underlying type. This is specifically problematic when considering thread safety (which a readonly interface does not guarantee). Plus these is no ReadOnlySet<T> AFAIK (#29387).

Author:	ohadschn
Assignees:	-
Labels:	area-System.Collections, untriaged, area-Extensions-Configuration
Milestone:	-

[layomia]

Related to #44493.

This seems like an enhancement request. @dotnet/area-extensions-configuration @davidfowl @ericerhardt it looks like a plethora of collection types are supported for configuration binding. How do we determine what types to support? Do we want collection support in the .NET 8 version of the ConfigurationBinder source generator?

[ohads-MSFT]

How do we determine what types to support?

If I could offer my 2 cents, considering the nature of options classes in general and their ASP.NET usage specifically, I think the concurrent readonly scenario is extremely common.

Recall that options classes are cached which means virtually all DI consumers would get the same options class instance (for example, each controller instance created for a request). This basically makes it a concurrent scenario automatically (where readonly is virtually assumed).

While it is true that IReadOnlyXXX binding works and serves this purpose the gold standard would be immutable collections for sure (for example see https://stackoverflow.com/questions/30165810/why-use-immutablelist-over-readonlycollection).