C# – Is services.AddSingleton really needed in .net core 2 API

.net coreasp.net-core-2.0asp.net-core-webapicconfiguration

I accessed appsettings.json In .NET Core 2 Web API Controller simply by adding below:

public class MyController : Controller
    {
        private readonly IConfiguration appConfig;

        public MyController(IConfiguration configuration)
        {
            appConfig = configuration;
        }
    }

Without adding below in Startup class ConfigureServices(IServiceCollection services) after services.AddMvc();:

services.AddSingleton<IConfiguration>(Configuration);

Is there any flaws in my approach? In official docs for .Net Core 2 configuration section, its not mentioned to use 'AddSingleton' not even once: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration

also by searching I couldn't find related content with accessing configuration!
https://docs.microsoft.com/en-us/search/index?search=AddSingleton&scope=ASP.NET+Core

Links below shows AddSingleton as if mandatory step:

Access appsettings.json values in controller classes

https://blogs.technet.microsoft.com/dariuszporowski/tip-of-the-week-how-to-access-configuration-from-controller-in-asp-net-core-2-0/

Best Answer

As the official roadmap for ASP.NET Core 2.0 says:

An IConfiguration instance will be added to the services container by default in ASP.NET Core 2.0, so that all applications can easily retrieve configuration values via the container

So services.AddSingleton<IConfiguration> (or similar) is already called by the framework itself.

You may see this behavior inside WebHostBuilder.cs file or (when using the utility extension methods) inside HostBuilder.cs file.

Related Solutions

C# – Reading settings from app.config or web.config in .NET

For a sample app.config file like below:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="countoffiles" value="7" />
    <add key="logfilelocation" value="abc.txt" />
  </appSettings>
</configuration>

You read the above application settings using the code shown below:

using System.Configuration;

You may also need to also add a reference to System.Configuration in your project if there isn't one already. You can then access the values like so:

string configvalue1 = ConfigurationManager.AppSettings["countoffiles"];
string configvalue2 = ConfigurationManager.AppSettings["logfilelocation"];

.net – the difference between .NET Core and .NET Standard Class Library project types

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of applications that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core applications to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with applications that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core, but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library, whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Conversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

Here is an interactive matrix that shows which .NET Standard supports which .NET implementation(s) and how much API surface area is available.

Best Answer

Related Solutions

C# – Reading settings from app.config or web.config in .NET

.net – the difference between .NET Core and .NET Standard Class Library project types

Related Topic