Repository navigation
The "Collection was of a fixed size." exception when configuring options. #77725
Description
Description
Exception thrown from the collection when configuring and options. This bug happens when we configure the options using the Configure callback AFTER the Bind extension is called.
This happens when you are using non-concrete collection type in our options:
public class MyOptions
{
public IList<string> MyList { get; set; } = new List<string>();
}I suspect that the Bind extension materializes incorrect IList type that has a fixed size. and no more items can be added to it after that.
We use this pattern across our codebase, and it breaks our scenarios completely. It blocks us from migrating to .NET 7. Full repro source here
Reproduction Steps
Run the following code in .NET 7.0 RC2 console app:
var config = new ConfigurationBuilder()
.AddInMemoryCollection(new Dictionary<string, string?>() {{ "MyList:0", "item1" }})
.Build();
var services = new ServiceCollection();
services
.AddOptions<MyOptions>()
.Bind(config)
.Configure(o => o.MyList.Add("xxx"));
var val = services.BuildServiceProvider().GetRequiredService<IOptions<MyOptions>>().Value;
Console.WriteLine("List size: {0}", val.MyList.Count);
public class MyOptions
{
public IList<string> MyList { get; set; } = new List<string>();
}Expected behavior
The code snippet above should work.
Actual behavior
When trying to add a new item to a list the list throws the following exception:
Unhandled exception. System.NotSupportedException: Collection was of a fixed size.
Regression?
No response
Known Workarounds
Change the collection to a concrete type. i.e. IList<string> -> List<string>
Configuration
Running on .NET 7 using the default console template.
Other information
No response
Activity
geeknoid commentedon Nov 1, 2022
Very important thing to note. This is new behavior in .NET 7, this bug was not present in previous versions of .NET. This change in .NET behavior breaks a lot of our code and our customer's code.
tarekgh commentedon Nov 1, 2022
We'll take a look soon at this one. Thanks for your report.
tarekgh commentedon Nov 1, 2022
CC @SteveDunn as FYI.
SteveDunn commentedon Nov 2, 2022
Hi, happy to fix, but unfortunately I'm not free until the weekend. Will this go into .NET 7?
stephentoub commentedon Nov 2, 2022
What change regressed this, @tarekgh / @SteveDunn?
tarekgh commentedon Nov 2, 2022
@stephentoub we are going to investigate as I mentioned in #77725 (comment)
tarekgh commentedon Nov 2, 2022
#73267
stephentoub commentedon Nov 2, 2022
@eerhardt
eerhardt commentedon Nov 2, 2022
Before #68133, the checks were fairly simple:
runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs
Lines 380 to 396 in fe21795
This would fall to
BindCollection, which would just add to the existing object instance.Now, we are checking upfront if the property's type is compatible with an array, and if it is, copying the current instance's values + the config values into a new array:
runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs
Lines 302 to 307 in 78cf32a
This is incorrect for "mutable" collection types (like
IList<T>andICollection<T>). For those types, we should just be appending to the existing instance, if there is one.tarekgh commentedon Nov 2, 2022
@eerhardt I am working on a fix. We need to first create instance
using List<T>if it is not created yet before binding. Anyway, let you know what I'll get.tarekgh commentedon Nov 3, 2022
I opened #77857 to fix this issue.
geeknoid commentedon Nov 4, 2022
I presume the fix isn't going to make .NET 7's initial release?
stephentoub commentedon Nov 4, 2022
Correct. It would be in a subsequent servicing release.
tarekgh commentedon Nov 11, 2022
This is fixed by the PR #78118. The fix will be in the next 7.0 service release.