Does ConfigurationManager.AppSettings[Key] read from the web.config file each time?

Question

I'm wondering how the ConfigurationManager.AppSettings[Key] works.

Does it read from the physical file each time I need a key? If so, should I be reading all the app settings of my web.config in a cache and then read from it?

Or does ASP.NET or IIS load the web.config file only once at application startup?

How do I verify whether the physical file is accessed by each read? If I change the web.config, IIS restarts my application, so I can't verify it that way.

Answer 1

It gets cached, on first access of a property, so it does not read from the physical file each time you ask for a value. This is why it is necessary to restart an Windows app (or Refresh the config) to get the latest value, and why an ASP.Net app automatically restarts when you edit web.config. Why ASP.Net is hard wired to restart is discussed in the references in the answer How to prevent an ASP.NET application restarting when the web.config is modified.

We can verify this using ILSpy and looking at the internals of System.Configuration:

public static NameValueCollection AppSettings
{
    get
    {
        object section = ConfigurationManager.GetSection("appSettings");
        if (section == null || !(section is NameValueCollection))
        {
            throw new ConfigurationErrorsException(SR.GetString("Config_appsettings_declaration_invalid"));
        }
        return (NameValueCollection)section;
    }
}

At first, this does indeed look like it will get the section every time. Looking at GetSection:

public static object GetSection(string sectionName)
{
    if (string.IsNullOrEmpty(sectionName))
    {
        return null;
    }
    ConfigurationManager.PrepareConfigSystem();
    return ConfigurationManager.s_configSystem.GetSection(sectionName);
}

The critical line here is the PrepareConfigSystem() method; this initializes an instance of the IInternalConfigSystem field held by the ConfigurationManager - the concrete type is ClientConfigurationSystem

As part of this load, an instance of the Configuration class is instantiated. This class is effectively an object representation of the config file, and appears to be held by the ClientConfigurationSystem's ClientConfigurationHost property in a static field - hence it is cached.

You could test this empirically by doing the following (in a Windows Form or WPF app):

1. Starting your App up
2. Access a value in app.config
3. Make a change to app.config
4. Check to see whether the new value is present
5. Call ConfigurationManager.RefreshSection("appSettings")
6. Check to see if the new value is present.

In fact, I could have saved myself some time if I'd just read the comment on the RefreshSection method :-)

/// <summary>Refreshes the named section so the next time that it is retrieved it will be re-read from disk.</summary>
/// <param name="sectionName">The configuration section name or the configuration path and section name of the section to refresh.</param>