Menu
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:
905
Application configuration in ASP.NET Core is performed using one or more configuration providers. Configuration providers read configuration data from key-value pairs using a variety of configuration sources: Settings files, such as appsettings. json.
ConfigurationManager was added to support ASP.NET Core's new WebApplication model, used for simplifying the ASP.NET Core startup code.
App. Config is an XML file that is used as a configuration file for your application. In other words, you store inside it any setting that you may want to change without having to change code (and recompiling). It is often used to store connection strings.
In order to set up the ASP.NET Core Module correctly, the web. config file must be present at the content root path (typically the app base path) of the deployed app.
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.
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.
125
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
