Understanding the new ASP.net 5 Configuration in Startup.cs

ASP.net 5 has so many changes in it I’m starting to lose track. I know it’s all good stuff but there is a lot of cheese moving at the moment, although RC1 has reduced that a lot now. One element which I needed to understand a little more about was Configuration.

This little sucker in Startup.cs and how to use it;

Lets take a look at how the values get in there first

Internally Configuration is just a key value pair with some functions, awesome. I’m all about keeping it simple.
IConfigurationRoot implements IConfiguration

When you define a ConfigurationBuilder you can give it any number of Sources in a nice chaining syntax. Each source (also called Provider) will be enumerated through and will produce a Key:string and a Value:string list.

In the case of AppSettings.json
would produce something like;
"AppSettings:StorageConnectionString", "MySuperSecretString"
"AppSettings:SomeOtherSetting", "false"

When you call ConfigurationBuilder().Build() it will flatten out the configs into simple keys and values.

More hierarchy just means more colons (:) in the key, just like a file path.

In the Environment Variable example it’s a straight copy. For instance;

Will become;

However suppose you have conflicting settings, two JSON files who both produce the same key. The Configuration object would still remember all the original settings and where they came from. But if you tried to access the key the value would come from the newest source specified. This is exactly by design and a really elegant way or managing settings over multiple environments.

For instance, when (not if) you deploy to Azure you want to use the app settings from within the portal not the appSettings.json. So the ‘.AddEnvironmentVariables();‘ does exactly that with out you have to change a single line of code. In Azure App Settings you create settings with keys like ‘AppSettings:DbContext’. Azure is making the App Settings in the portal into environment variables and your solution is seamlessly pulling them into your app over your local settings.

A very neat solution but it does come with a caveat. Don’t get the ordering of the config sources wrong. It’s pretty easy in my example but a more complex solution would easily hide this subtle piece of the system.

Strong Typing Configuration Sections

So we know how to get config options into the application but how do we get at them? Easy Configuration["SomeKey"]. Easy for the odd value but crap if you want to get a load of settings.

We need to strong type the settings into a POCO. We can do this in two very simple steps.

  1. First build the POCO, something like this;
    public class AwesomeConfig
        public string Thing1 { get; set; }
        public string Thing2 { get; set; }
        public AwesomeConfig()
  2. Then to push the config values into the POCO use; services.Configure<AwesomeConfig>(Configuration.GetSection("Awesome"));

So after a suitably deep look into the configuration part of ASP.net 5 I’m still happy. It all makes sense and nothing is hidden from view and easily configurable.

Slick stuff Mr ASP.net *I doth my cap


  1. Darren

    Hey Mike,

    This is a great write up and I have to say I love this setup. It means you can split your configuration into separate files as you see fit and have environment variables pulled in and merged as the last step. However, I have a question regarding reading config settings into a POCO. Since the settings can be arbitrarily deep (i.e. “Awesome:MySection:MyValue”), could you arbitrarily read a nested section into a POCO or is it only top-level sections that can be read in?


    If I have the time to get to this experiment I’ll post back with the results.


    1. mikemengell

      Hi Darren,

      Yeah it supports exactly what you’re looking for. They think of everything those clever ASP.net dudes.

  2. Lee

    In your screen-shot of the Iconfiguration interface, is that method commenting syntax supported by Visual Studio in an official way? I rather like it.

Leave a Reply

Your email address will not be published. Required fields are marked *