WCF: appSettings values not seen in nested web.config files

I recently ran into an issue with an WCF application that had services in sub-folders AND each one had it's own web.config file. When the app pool was reloaded after a period of time, appSettings would appear to have vanished when using the standard ConfigurationManager to retrieve them.

The WCF services were derived from a common base class that used some appSettings values. I had to place each service in sub-folders so each service could have their own copy of the appSettings values used by the base class. There are other known problems with WCF and web.config files; these are resolved by adding the aspNetCompatibilityEnabled element to the ServiceModel section of the web.config. I had already done this to fix earlier issues.

This new problem seemed to occur after the app pool was reloaded after being idle. It is like the service didn't even see the web.config in the sub-folder.

To fix the issue I had to create a separate Configuration object and manually point it to use the web.config from the virtual path of the web service in the sub-folder. I created a tiny helper class to read the appSettings for the web services:

/// <summary>
/// This class is used to retreive appSettings values from a configuration file.  Special
/// support is provided when nested web.config files are used since pre .NET 4.0 are broken
/// in terms of nested web.config settings.
/// </summary>
public class WcfAppSettings
{
   private readonly Configuration _config;

   public WcfAppSettings()
   {
      VirtualPathExtension extension = OperationContext.Current.Host.Extensions.Find<VirtualPathExtension>();
      _config = WebConfigurationManager.OpenWebConfiguration(extension.VirtualPath);
   }

   public string this[string key]
   {
      get
      {
         return _config.AppSettings.Settings[key].Value;
      }
   }
}

Then I can then use the above class like:

WcfAppSettings appSettings = new WcfAppSettings();
string x = appSettings["MySettingKey"];

This appears to have fixed the issue. This is supposed to be fixed in .NET 4.0.