In The Olden Days
In a web.config file, settings could be placed in an appSettings section like so:
<appSettings>
<add key="mysetting" value="123"/>
</appSettings>
Even though my web.config file was in my web project, any assemblies/libraries used in that project could access the settings using:
ConfigurationManager.AppSettings["mysetting"]
Today (and the problem)
I am starting to use .NET core, and just like before, I have assemblies/libraries that are not web projects in of themselves and need to access various configuration settings.
Microsoft's Configuration documentation (https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration) along with all of the other examples I can find, have the configuration class being consumed by a controller and don't provide any guidance on how to make it work with a class in another assembly/library that is not a controller.
For ONE example, if I have a custom attribute that I can decorate a class with and that custom attribute is defined in another library (not in a web project) and it needs to access a configuration setting, how do I do that today? I can't pass in anything to a constructor in such an instance either.
I'm going to assume you're talking about a ASPNET Core project as you specifically mention web.config.
Here's what you need to do.
IOptions<FooSettingsClass> is usually configured at application start which means that it's available at runtime with code that looks something like this.
// Adds services required for using options.
services.AddOptions();
services.Configure<AppSettings>(Configuration.GetSection("FooAppSettings"));
The easiest way is to have the framework inject it through the constructor. Typically you'll see it (as you mentioned) being injected in the controller like this:
class FooController : Controller {
public FooController(IOptions<FooSettingsClass> settings) { .
//..
}
}
If you need to access this configuration is say, a service, then you simply have a constructor, in a different assembly, which accepts those options. So:
public class SomeServiceInAnotherAssembly {
public SomeServiceInAnotherAssembly(IOptions<FooSettingsClass> settings) {
//..
}
}
This obviously means that your FooSettingsClass class needs to be outside of your ASPNET Core project (to avoid circular dependencies), but this is one way of propagating your configuration without writing any code, which is what I've seen other developers do. To me, writing code is a hoop jumping solution bound to have bugs.
Don't forget that your class (in this exampe SomeServiceInAnotherAssembly) needs to be registered at startup, i.e. services.AddScoped<SomeServiceInAnotherAssembly>();
The nice thing about this approach is that it makes your classes testable.
In 8-2017 Microsoft came out with System.Configuration.Manager for .NET CORE v4.4. Currently v4.5 and v4.6 preview.
Install this nuget package. Add directive to a code file
using System.Configuration;
Now, you can do your
var val = ConfigurationManager.AppSettings["mysetting"];
There is one trick for web sites though - you no longer use web.config for application settings and configuration sections. You use app.config as well as other types of projects. But if you deploy in ISS, you might need to use both. In web.config you supply strictly ISS-related entries. Your app-specific entries go to app.config
