With ASP.NET Core 1.0 released, writing .NET code is changing dramatically. I'm not going to say that someone moved your cheese, but rather deleted it.

Configuration in ASP.NET Core is a tad bit different from the ConfigurationManager.AppSettings we're used to when grabbing application settings. In this post, I'll show you a quick way to set up your settings for your ASP.NET Core application.

Need Some Class-y Settings

Gone are the days of slapping something into a web.config and reading it. We need to bring some structure to our configuration. Our configurations now use classes, so let's create our application settings class in a Configuration folder.

Configuration/DemoSettings.cs

public class DemoSettings
{
    public string MainDomain { get; set; }
    public string SiteName { get; set; }
}

We created some simple properties to hold our settings.

Our appsettings.json will now look like this:

{
  "DemoSettings": {
    "MainDomain": "http://www.mysite.com",
    "SiteName": "My Main Site"
  },
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }
}

Now we need to explain our Startup.cs file.

Configuring the Services

The Startup.cs is where we define all of our settings for our application whether it be SQL Server, MVC, a plain file server, or whatever suits your fancy with ASP.NET Core. The whole idea is that you are configuring your pipeline using middleware.

In our startup.cs file, you'll notice the ConfigureServices method. 

public void ConfigureServices(IServiceCollection services)
{

    services.AddMvc();
}

For our custom configuration to work properly, we need some additional services.

public void ConfigureServices(IServiceCollection services)
{

    services.AddMvc();


    services.AddOptions();


    services.Configure<DemoSettings>(Configuration.GetSection("DemoSettings"));


    services.AddSingleton<IConfiguration>(Configuration);
}

The AddOptions() is the setup for allowing IOptions<T> to be injected into your code.

The Configure method tells your configuration that we are defining a DemoSettings section in your appsettings.json file and it will hold the DemoSettings object data.

Finally, we create the dependency injection for our configuration as a singleton.

Injecting Our Options

Our configuration is now available through dependency injection.

If we want to use a configuration setting in our controller (like the SiteName), we need two things: a property to hold our settings and a constructor to perform constructor injection.

Controllers/HomeController.cs

public class HomeController : Controller
{
    private DemoSettings ConfigSettings { get; set; }

    public HomeController(IOptions<DemoSettings> settings)
    {
        ConfigSettings = settings.Value;
    }

 public IActionResult Index()
    {
        ViewData["SiteName"] = ConfigSettings.SiteName;
        return View();
    }
}

The property ConfigSettings will hold our settings in the controller, and once the controller is instantiated, our settings will be injected through the constructor.

As you can see in our Index(), we pass the SiteName over to the view through our ViewData (it would be better if it was passed using a ViewModel).

Conclusion

While the ConfigurationManager has disappeared for ASP.NET Core applications, it's been replaced with something a little more decoupled and provides a more structured way of saving configuration settings for your application.

We demonstrated an easy way to pass your configuration settings around using depedency injection.

Was this demonstration helpful? Do you want to see more ASP.NET Core 1.0 features? Which features? Post your comment below and let's discuss.