Configuration file is read twice / performance problem


<p>We use a custom initialization of the Entlib 5 to prevent running any config change listeners, but enable application programmers that do not call / use the function with the code below to still use the fully configured entlib using the FileConfigurationSource element in the many app.config&#39;s. Here is the code we use to init the &quot;watcherless&quot; entlib: </p> <p>&nbsp;</p> <p>// filePath is the full file name incl. path of the entlib.config:</p> <p>EnterpriseLibraryContainer.Current = EnterpriseLibraryContainer.CreateDefaultContainer(new FileConfigurationSource(filePath, false));</p> <p>&nbsp;</p> <p>Now it happened, we are bothered by (still open issue) http://entlib.codeplex.com/workitem/26990 within a web service project and detected a &quot;chicken and egg problem&quot; with the code above:</p> <p>The static method called (EnterpriseLibraryContainer.CreateDefaultContainer) goes into a &quot;self-init&quot; mode of the Entlib, adding extensions required, that in turn call into UnityContainerConfigurator.ctor(IUnitiyContainer) and then into AddValidationExtension() function. This functions load a (not referenced) type &quot;Microsoft.Practices.EnterpriseLibrary.Validation.Configuration.Unity.ValidationBlockExtension&quot; if present (it is present in our case). The init of the base class of this type (EnterpriseLibraryBlockExtension). The Initialize() method at that base type has code like this:</p> <p>&nbsp;</p> <p> if (base.Container.Configure&lt;EnterpriseLibraryCoreExtension&gt;() == null)</p> <p> {</p> <p> base.Container.AddExtension(new EnterpriseLibraryCoreExtension(ConfigurationSourceFactory.Create()));</p> <p> }</p> <p>&nbsp;</p> <p>Because there is no EnterpriseLibraryCoreExtension configured (we are in the init sequence!) it will call into ....AddExtension() with a ConfigurationSourceFactory.Create() call - that failed to run, because of the issue 26990 mentioned above in web service environment, but succeeds for normal clients (exe). And there we now have the double read config file impact now, if the call succeeds. This code sequence took a second all the time I measured at my quad core i7 laptop and is within the top five time consumers in a database application.</p>


ctavares wrote Dec 10, 2010 at 6:03 PM

Wow, that's a big whoops. There should be a way to work around the issue until we fix it... give me a little while to dig into the code and find an alternative initialization sequence for you.

gmelnik wrote May 6, 2011 at 3:54 AM

Fixed in Enterprise Library 5.0 Optional Update 1

MariusFili wrote Sep 22, 2011 at 12:38 PM

I applied the Optional Update on my sources but this effect is still in place... could you please point out which change did solve this problem?