Microsoft.Extensions.Configuration add the ability to bypass "FormatException: A duplicate key"

[sb-viktor]

I'm using Microsoft.Extensions.Configuration.Ini v:9.0.2 and I get a FormatException every time I open the .ini file. For example I have this ini:

...

[UART]
Use = 1
Baudrate = 115200
COM = 31
COM = 25

...

And I build it into a configuration object:

IConfiguration config = new ConfigurationBuilder()
    .AddIniFile(filePath)
    .Build()

Then we get:

System.IO.InvalidDataException: 'Failed to load configuration from file 'filePath'.'
Inner Exception
FormatException: A duplicate key 'UART:COM' was found.

---

I want IConfigurationBuilder to overwrite the value itself. The last written value will be the value that will get to IConfigurationBuilder. If we consider the same example, the final COM value will be 25

[dotnet-policy-service]

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

[tarekgh]

Can't you fix the ini file? why you have duplicate values there in the first place?

[julealgon]

Can't you fix the ini file? why you have duplicate values there in the first place?

I think the issue is that you could argue "there is nothing wrong with the ini file" too @tarekgh . At least according to Wikipedia, this part of the format is provider-dependent:

• https://en.wikipedia.org/wiki/INI_file#Duplicate_names

Due to this, I think providing which behavior you want explicitly would be an interesting change.

[tarekgh]

Well, I was not trying to argue here more than figuring out if this is acceptable workaround. But looking at the link you pasted it states the following:

Duplicate names
Most implementations only support having one property with a given name in a section. The second occurrence of a property name may cause an [abort](https://en.wikipedia.org/wiki/Abort_(computing)), it may be ignored (and the value discarded), or it may override the first occurrence (with the first value discarded). Some programs use duplicate property names to implement multi-valued properties.

Interpretation of multiple section declarations with the same name also varies. In some implementations, duplicate sections simply merge their properties, as if they occurred contiguously. Others may abort, or ignore some aspect of the INI file.

It is up to the implementation to decide what to do with the duplicate entries. The option to abort is what currently the configuration does which still comply to this spec.

Anyway, I am not objecting to the idea in this issue, but I am seeing this is low priority to consider in the current time.

[sb-viktor]

Can't you fix the ini file? why you have duplicate values there in the first place?

That's a good question, @tarekgh. Of course I can do that, but I'm working on a project that the old development team left. They left over 300 configs and all of them have key duplication:

Apparently the parser they used for the old project could easily accept duplication and just overwrite the value.

I can also write a parser to fully manage the data and work with the file, but I still want to use the modern features of .NET

I do not think there should be duplication in the ini . At least it creates problems with the readability of the config. But I need both to maintain the old project (because many people use it) and to use modern .NET technologies rather than writing shitty parsers.

Correction: You might think the problem is that I'm just lazy and can't rewrite the configs. I'm not. The problem is that the old project and the configs are used by a lot of people, and if you rewrite them, there is a chance that they will not work (or will not work properly) with the old project.

[KalleOlaviNiemitalo]

Duplicate keys were also discussed in #36557 and #99535.

[tarekgh]

@KalleOlaviNiemitalo thanks for the links.

The problem is that the old project and the configs are used by a lot of people, and if you rewrite them, there is a chance that they will not work (or will not work properly) with the old project.

@sb-viktor thanks for your detailed reply. I do not fully understand this. If you write a simple tool sanitize the ini files just one time act, how will this break anyone using the old projects? Do you think old projects depend on duplicate values in the ini? That will be very weird and wrong behavior anyway.

[tarekgh]

CC @ericstj

[sb-viktor]

Do you think old projects depend on duplicate values in the ini? That will be very weird and wrong behavior anyway.

@tarekgh honestly, I don't know how it works.

If you write a simple tool sanitize the ini files just one time act, how will this break anyone using the old projects?

That's not a problem, and that's what I'm doing. I just want this feature to be in the Microsoft.Extensions.Configuration itself.