Enterprise Logging Block very slow to retrieve first LogWriter instance

Topics: Logging Application Block
Jun 21, 2010 at 8:40 PM
Edited Jun 21, 2010 at 9:06 PM

We're deploying an application that uses the Logging Block to a set of machines on a "very secure" network. Upon doing so, we're experiencing some very unusual characteristics from the EntLib. We've tracked our performance problems down to the retrieval of the initial instance of a LogWriter class ( private LogWriter writer = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>(); ). For some reason it takes approximately 20 seconds to create and retrieve this initial instance. Once it's created subsequent calls execute instantly. Has anyone experienced similar problem with slowness of the EntLib? Does anyone have any advice on where to look to determine the root cause of this issue? We're stuck, and we really want to EntLib logging in the application.

We're using version 5 of EntLib. Currently it doesn't matter what listener we have configured, it's slow to initialize. For test purposes we have been using a Flat File.

Jun 22, 2010 at 10:28 AM

Hi JonDowney,

As far as I know there are none so far any reported performance issue regarding the instantiation of a LogWriter object. Does this happen consistently? What happen if you test the instantiation alone let say for example in a console app that only contains code which instantiate the LogWriter, does it still take ~20 seconds? From our end it only takes ~3 seconds to instantiate a LogWriter.

Gino Terrado
Global Technology and Solutions
Avanade, Inc.

Jun 22, 2010 at 1:36 PM
Edited Jun 22, 2010 at 6:04 PM

We have already tried the approach you have suggested below and it had no effect on the instantiation of the object.

This problem may be bigger than previously thought. We've also noticed that the Configuration Console takes over 30 seconds to start up on this set of machines. On a normal PC it's up and running in a second or so.

We are suspecting that the set of machines we are working on are locked down so tight that something is trying to happen but ends up timing out instead. The problem here is that we haven't been able to identify the culprit. Please keep in mind that these machines are extremely secure and you can't take anything for granted with them. Services may or may not be running, directory permissions may or may not exist, etc.



Jun 22, 2010 at 6:41 PM

Well, first time launch of WPF apps in general is kind of slow. Is the delay every time you launch the config console or every time. Is it 30 seconds before you see the splash screen or 30 seconds before you can use the app?

I agree, it sounds like a timeout of some sort, but I can't think of anything special we're doing that would cause that. Does this happen with other signed .NET assemblies? It could be timing out trying to verify the signature on the assembly if internet access is locked out.


Jun 22, 2010 at 7:09 PM


 I think you're on to something...

The delay occurs every time you launch the Config Console or every time you launch an application that uses the EntLib. Internet access is locked out on these machines. Is there a way to sign the assemblies with a more "private" SNK so internet access is not needed?


Jun 23, 2010 at 12:21 AM

The internet access is required for the Authenticode signature, actually, not the strong name.

There's a config switch that can be used to turn off authenticode verification. Try adding this:

  <generatePublisherEvidence enabled="false"/>

into your app.config file and see if it helps.

Also, which .NET framework are you targeting? They changed this behavior in .NET 4.0, so if you're on 4.0 then don't bother, this isn't the issue.


Jun 23, 2010 at 1:37 PM


You hit the nail on the head. I added the config switch to my test application as well as the app.config file for the EntLibConfig tool and both load almost instantly.

For the record, we're running .NET framework 3.5 sp1.

Thanks for your help on this one!


Nov 8, 2010 at 2:57 PM


Is it possible to turn this off in the EntLib sources code. We're working on another project and running into an issue with the solution above. This time we're writing an assembly that is loaded by a 3rd party .EXE. The third party .EXE does not use an app.config file, so I can't set the setting above. I'm looking for a way to go into the EntLib source and turn this off once and for all. Any suggestions.


Nov 8, 2010 at 3:14 PM

Scratch that, did some more digging and fould the solution at: http://social.msdn.microsoft.com/forums/en/vbgeneral/thread/d303523f-217c-46f8-b3c2-763864f97b52/