Make Microsoft.Extensions.Configuration.Xml more tolerant against not supported XML features

[amaic]

I ran into a problem with the current implementation of Microsoft.Extensions.Configuration.Xml.

With Visual Studio 2019 16.2.1 I created a new Console App (.NET Framework) application,
added NuGet packages Microsoft.Extensions.Configuration.Xml and NLog.Extensions.Logging,
added code var configuration = new ConfigurationBuilder().AddXmlFile(Assembly.GetExecutingAssembly().Location + ".config").Build();
into main function,
started the program and got an exception:

System.FormatException
HResult=0x80131537
Message=XML namespaces are not supported. Line 7, position 22.
Source=Microsoft.Extensions.Configuration.FileExtensions
StackTrace:
at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load(Boolean reload)
at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load()
at Microsoft.Extensions.Configuration.ConfigurationRoot..ctor(IList`1 providers)
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at ConsoleApp1.Program.Main(String[] args)

I looked into the generated app.config file and found following XML data:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
    </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Configuration.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Primitives" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

The reason of FormatException is attribute "xmlns" of element "assemblyBinding".

I wonder, why files with XML namespace declarations are completely rejected.

My expectation would be, that XML features, that are not yet implemented or cannot be implemented due to their nature of not being mappable to key-value-pairs,
are ignored, perhaps writing a warning into log file and all other elements are loaded into memory.

So does it make sense to change the behaviour, instead of throwing an exception ignoring such elements and write a warning into log file?

[Andrey-32rus]

I have the same problem and want to know about solution of this problem

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[brumlemann]

What happened to this one? Superseded by another solution without trace or just stale (as hinted too) because of no action?

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I ran into a problem with the current implementation of Microsoft.Extensions.Configuration.Xml.

With Visual Studio 2019 16.2.1 I created a new Console App (.NET Framework) application,
added NuGet packages Microsoft.Extensions.Configuration.Xml and NLog.Extensions.Logging,
added code var configuration = new ConfigurationBuilder().AddXmlFile(Assembly.GetExecutingAssembly().Location + ".config").Build();
into main function,
started the program and got an exception:

System.FormatException
HResult=0x80131537
Message=XML namespaces are not supported. Line 7, position 22.
Source=Microsoft.Extensions.Configuration.FileExtensions
StackTrace:
at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load(Boolean reload)
at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load()
at Microsoft.Extensions.Configuration.ConfigurationRoot..ctor(IList`1 providers)
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at ConsoleApp1.Program.Main(String[] args)

I looked into the generated app.config file and found following XML data:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
    </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Configuration.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Primitives" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

The reason of FormatException is attribute "xmlns" of element "assemblyBinding".

I wonder, why files with XML namespace declarations are completely rejected.

My expectation would be, that XML features, that are not yet implemented or cannot be implemented due to their nature of not being mappable to key-value-pairs,
are ignored, perhaps writing a warning into log file and all other elements are loaded into memory.

So does it make sense to change the behaviour, instead of throwing an exception ignoring such elements and write a warning into log file?

Author:	amaic
Assignees:	-
Labels:	area-Extensions-Configuration, untriaged
Milestone:	-

[AleksandrEfimov]

Yes, it`s the problem. I simply wanted get configuration from old App.config after migration from .net 4.7.1 to Core 3.1.
Please save hours of live other programmers - solve this issue.

[ericstj]

CC @maryamariyan @eerhardt

I can imagine folks might have preferences both ways. Some folks might feel confused if we silently dropped members of the XML document, not realizing that it was due to the namespace. That feels like much worse behavior than simply disallowing the namespace.

What's the scenario for actually using Microsoft.Extensions.Configuration.Xml with namespaces? I see above folks are using it to read a ,NETFramework app.config which doesn't seem like a good idea. Those are meant to be backed with strongly typed configuration data types and much fidelity will be lost. The format expected by Microsoft.Extensions.Configuration.Xml is much simpler: https://docs.microsoft.com/en-us/dotnet/core/extensions/configuration-providers#xml-configuration-provider.

Maybe I'm missing something here. What's leading folks to use XML files that have namespaces and other content that's not meant for M.E.C.XML?

[Trinitron]

I do not want to create a new issue for that, but Microsoft.Extensions.Configuration lib disrespects key/value pairs from App.config files: https://docs.microsoft.com/en-us/troubleshoot/dotnet/csharp/store-custom-information-config-file
It blocks app inicialization process for AzureFunctions (in my case) with this error:
[2021-08-10T08:22:48.508Z] A host error has occurred during startup operation '63d277b2-fefe-4ebd-87ec-d7c2f59051ef'.
[2021-08-10T08:22:48.510Z] Microsoft.Extensions.Configuration.Xml: A duplicate key 'appSettings:add:key' was found. Line 5, position 10.
This is a general XML configuration file (with this problem) you can take from the link above:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="Key0" value="0" /> <add key="Key1" value="1" /> <add key="Key2" value="2" /> </appSettings> </configuration>
Every key in appSettinngs treat like duplicate without specifying 'name' attribute.

[drarleigh]

It would be nice to make this work. "Using it to read a ,NETFramework app.config" may not sound like a good idea but it sounds like a good transition strategy to me. We have a lot invested in our config files and we would like to leverage that as we introduce newer functionality that works with an instance of IConfiguration.