Our virtual home

How to prevent the configuration file watcher thread in Microsoft Enterprise Library 3.1

I have not blogged very much the last time, but now I'm back to write about some interesting things again. Lets start with the Microsoft Enterprise Library. For some reasons we are still bound to version 3.1, so the following is valid for that version only - it might not work with the newer version 4.x yet available.

So what I'm writing about? If you ever run a trace tool for an application using the Entlib you might have considered a separate thread "ConfigurationChangeFileWather" (right, it is misspelled - but that thread name is set by the Entlib, sorry). How comes? If you don't need this service (config changes are monitored while the application is running) there is not much information about it how to disable that (especially if you run in ASP.NET with the Entlib). Google around, the most answers I found are: you cannot disable that without modifying the Entlib source code (you can, but who will ever really do this and maintain it over the versions?). So I will describe a scenario, how we use it and how we disable that thread (consuming resources, because it polls the file change date).

For all, that don't like to read the full story: you just have to call

FileConfigurationSource.ResetImplementation(filePath, false);

The filePath variable should point to the Entlib configuration file you use, the important parameter is the boolean. That's it!

But, you know that filePath is also a configuration entry, and hard-coding that is not really what you want. Our app.config files are looking like this, your file might be similar:

 <configuration>
 <configSections>
  <section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  configSections>
 <enterpriseLibrary.ConfigurationSource selectedSource="File Configuration Source">
 <sources>
  <add name="File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" filePath="Module.EnterpriseLibrary.config" />
 sources>
enterpriseLibrary.ConfigurationSource>
 

The interesting parts are marked red. As you can see: you can have multiple sources, but only the selected source is important here. It has the filePath attribute, that points to the real Enterprise Library configuration file (that is monitored by the thread). So to make the call above dynamic, you have to get the value from the filePath attribute:

  public static string ModuleConfigurationFile
  {
    get {
      ConfigurationSourceSection section = ConfigurationSourceSection.GetConfigurationSourceSection();
      if (section != null && !String.IsNullOrEmpty(section.SelectedSource) &&
          section.Sources.Count > 0)
        {
          FileConfigurationSourceElement e = section.Sources.Get(section.SelectedSource) as FileConfigurationSourceElement;
          if (e != null)
            return e.FilePath;
          }
          return null;
        }
    }

First we get the section (enterpriseLibrary.ConfigurationSource) to read the selectedSource attribute content. If it is set, we read the corresponding source element and return the file path.

So now call the function mentioned above with the dynamic ModuleConfigurationFile property somewhere in your application startup phase -- no configuration file watcher anymore!

» Similar Posts

  1. More to know about .NET Timers
  2. RSS - Editing a yet published post should NOT change the post date
  3. Strange XSL Transform Exception - figured out

» Comments

  • Rich avatar

    Hi Torsten,Do you have any idea how to stop it in Enterprise Library 4.1?All of the settings are in Web.config, but if you pass in the name / relative / fully qualified path to this file it does nothing.I'm having real speed issues - it turns out that when every new request is made (FYI i'm using ASP.NET MVC) it kicks off a new thread which takes anywhere between 60% and 97% of the execution time - turning it from, say 1 second into 10 seconds per request.It's extremely annoying!Rich

    Rich — Februar 7, 2009 8:24
  • Rich avatar

    Hi,Update: the solution is to split the enterprise library config out into a separate file, then use the code above.Follow this guide to do so:http://www.pnpguidance.net/Post/EnterpriseLibraryExternalConfigurationSourceApplicationBlockSettings.aspxit now runs *much* faster!Rich

    Rich — Februar 7, 2009 9:30
  • TorstenR avatar

    I think the same solution is true for the version I described: I assumed, the Entlib.config is in a separate file (other than directly within the app.config). Nice to know it also works for 4.1, thanks!

    TorstenR — Februar 9, 2009 2:29
  • Darcy avatar

    You guys really rule.I am from Croatia and now study English, tell me right I wrote the following sentence: "Amadeus online - booking air tickets online tallinn airport timetables service charges."With respect ;), Darcy.

    Darcy — März 27, 2009 3:55
  • Comments are closed