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

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.

Solution 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>

Solution 2:

The simple answer is no, it doesn't always read it from the file. As some have suggested if the file is changed then IIS performs a restart but not always! If you want to guarantee that you are reading the very latest value from the file and not the cache you need to call something like this:

ConfigurationManager.RefreshSection("appSettings");
string fromFile = ConfigurationManager.AppSettings.Get(key) ?? string.Empty;

And an example I use in my code:

/// ======================================================================================
/// <summary>
/// Refreshes the settings from disk and returns the specific setting so guarantees the
/// value is up to date at the expense of disk I/O.
/// </summary>
/// <param name="key">The setting key to return.</param>
/// <remarks>This method does involve disk I/O so should not be used in loops etc.</remarks>
/// <returns>The setting value or an empty string if not found.</returns>
/// ======================================================================================
private string RefreshFromDiskAndGetSetting(string key)
{
    // Always read from the disk to get the latest setting, this will add some overhead but
    // because this is done so infrequently it shouldn't cause any real performance issues
    ConfigurationManager.RefreshSection("appSettings");
    return GetCachedSetting(key);
}

/// ======================================================================================
/// <summary>
/// Retrieves the setting from cache so CANNOT guarantees the value is up to date but
/// does not involve disk I/O so can be called frequently.
/// </summary>
/// <param name="key">The setting key to return.</param>
/// <remarks>This method cannot guarantee the setting is up to date.</remarks>
/// <returns>The setting value or an empty string if not found.</returns>
/// ======================================================================================
private string GetCachedSetting(string key)
{
    return ConfigurationManager.AppSettings.Get(key) ?? string.Empty;
}

This allows you to very easily choose (and when reading code see) whether you are getting the latest value each time or if you don't expect the value to change from when the application starts.

Solution 3:

var file = new FileInfo(@"\\MyConfigFilePath\Web.config");

DateTime first  = file.LastAccessTime;

string fn = ConfigurationManager.AppSettings["FirstName"];
Thread.Sleep(2000);

DateTime second = file.LastAccessTime;

string sn = ConfigurationManager.AppSettings["Surname"];
Thread.Sleep(2000);

DateTime third = file.LastAccessTime;

All show the same LastAccessTime which means it's cached at startup.

string fn1 = ConfigurationManager.AppSettings["FirstName"];
Thread.Sleep(2000);

DateTime fourth = file.LastAccessTime;