Is using app.config and ConfigurationManager in .NET core advisable?

Question

We are migrating some .NET applications from full framework to .NET core and we are trying to find out the best way to do so.

One of the major changes is the one related to the way applications are configured. In the .NET full framework we used to put application settings inside the app.config file and to read them by means of the ConfigurationManager class.

I know that .NET core supports a new configuration system based on the nuget package Microsoft.Extensions.Configuration and the various packges for the configuration sources. However, at the same time, Microsoft has extended the support for the ConfigurationManager class to .NET core, by means of the nuget package System.Configuration.ConfigurationManager.

Here are my questions:

• what is the intended best practice to configure .NET core applications ?
• the support for app.config file has been implemented only for backward compatibility, so that the porting to .NET core of legacy applications is easier, or it is considered a best practice and it will be maintained in the future ?

Answer 1

Some history, the original team to begin shrinking the dependencies included in a .Net application was the Asp.Net team. Microsoft's web framework was bloated compared to more modular frameworks, causing latency in request. According to Scott Hansleman whom frequently tells this joke in presentations:

Who here develops with .Net? Nobody under thirty, fantastic! So how do we combat this? Become modular, faster, cross platform, and easier to get started. Otherwise you would go, I want to learn to code. Download Visual Studio then four hours later write hello world.

So the web team began this transformation, which for the web makes JavaScript Object Notation a better choice than Extended Markup Language. But within a year of the Asp.Net team making these modifications Microsoft restructured their organization for a one .Net. They realized that these changes would cascade across more than just the Asp.Net team. The older project types would not be compatible or work with JavaScript Object Notation, so they transitioned back to Extended Markup for their .csproj and other configuration types. But a lot of developers really liked the JavaScript Object Notation files for settings, they are smaller, clearer, and not as verbose. So Microsoft added the feature back through Microsoft.Extensions.Configuration to allow you the flexibility.

• The primary purpose was for backwards compatibility.
• Ensure that it is updated for any .Net Standard application as well.

So you can leverage either. No real benefit, aside from Extended Markup tends to be incredibly tedious to read and verbose compare to a JavaScript Object. JavaScript Object Notation tends to be easier.