ConfigurationBuilder add elements to initialized array instead of replacing it

[Eilon]

From @LordXaosa on Thursday, 18 October 2018 09:39:00

Code:

class TestClass
        {
            public TestClass()
            {
                TestArray = new[] { "123", "test1" };
            }
            public string[] TestArray { get; set; }
        }
class MyConfig
        {
            public TestClass Test{ get; set; }
        }

MyConfig cfg = new MyConfig();
IConfiguration config = new ConfigurationBuilder()
                 .SetBasePath(AppDomain.CurrentDomain.BaseDirectory)
                .AddJsonFile("appsettings.json")
                .Build();
            config.Bind(cfg);

in appsettings.json:

{
  "Test": {
    "TestArray": [ "3", "4" ]
  }
}

I expect after config loading there would be only 2 items: "3" and "4"
But there would be all 4. "123","test1","3","4"
Consider this is a bug or there should be an option for replacing array values.

Copied from original issue: dotnet/aspnetcore#3666

[poke]

Judging by the existence of tests that verify exactly that the binder behaves that way, I would assume that this behavior is fully intended.

[LordXaosa]

Such behavior doesn't seem to be obvious... I really expected 100% equal objects in config and in runtime. May be there should be an option? Count this as suggestion.

[thviQit]

This is really bothering me as well. If I write something in my config.json, I expect it to overwrite default values, not add to it.
Basically it means you cannot have default values for collections/arrays, but always have to define them in your configuration. That is not the behavior I would expect.
Right now it giving me some headaches as I validate my option POCO with fluentvalidation, and that doesn't allow null properties.

[chuanboz]

+1 to fix this behavior.
Have some find some workaround before this is fixed?

[chuanboz]

As this would be a breaking change, can we consider it in asp.net core 3.0 that is expected to ship this fall?

[roblapp]

This is causing me a lot of grief. What is the plan for this?

[tvanbaak]

I am also having trouble because of this behavior. A fairly simple fix should be to add a BinderOptions flag that, if set, calls .Clear() on the collection before adding to it.

For anybody else having trouble with this in the meantime, creating a shim class inheriting from List<T> that calls .Clear() upon the first call to .Add() solves this for the list case, and there should be a similar solution for the Dictionary case.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.