IList<string> type always overrides values in config file

[sashazjukov]

Using Interface IList in property declaration will force overriding List values in config files.
public IList ServerList { get; set; }

[RickStrahl]

Can you be a little more specific? What are you doing? Code sample?

[sashazjukov]

in the example below use IList instead of List, and in the output config file you will not be able to change values of these keys:

< add key="ServerList1" value="DevServer" />
< add key="ServerList2" value="Maximus" />
< add key="ServerList3" value="Tempest" />

On every start the application will override values of ServerList in the output config file with values defined in constructor.

    public class CustomConfigFileConfiguration : Westwind.Utilities.Configuration.AppConfiguration
    {
         public string ApplicationName { get; set; }
         public IList <string> ServerList { get; set;  } //  <---- IList instead of List

        public CustomConfigFileConfiguration()
        {
            ApplicationName = "Configuration Tests";
            ServerList = new List<string>()
            {
                "DevServer",
                "Maximus",
                "Tempest"
            };
        }
    }

[dragnilar]

2 years later...

I was having this problem too. It was driving me nuts, because Rick was doing it without any problems in the unit tests for CustomConfigFileConfiguration. I took a look around and discovered that he wasn't using a custom configuration file in his test. I tried using the default file in mine, and lo and behold I was able to retrieve my list after writing and restarting or making a new config object. I then went back to his unit test and tried using a custom file, and his test would fail.

I dug a little deeper and found out that it's because the library doesn't do the same thing with Lists that it does when you don't tell it to use a custom file. I had to make a change to the source to get Lists to work with custom config files. I'm not sure if it's worth sharing though, since it feels like a hack. For what it's worth, the same "problem" exists in the full WestWind.Utilities' configuration class as well. But of course I could have just been doing it wrong this entire time, but I couldn't find any examples that would say otherwise and unfortunately the documentation website for this library seems to be down at the moment (http://west-wind.com/westwind.applicationconfiguration/docs).