Logger.Reset or LogWriter Instantiation

Topics: Logging Application Block
Jun 14, 2010 at 3:02 PM


We have some integration tests that we made for a wrapper we created on top of the Logging Application Block.

In some integration tests we need to check different TraceListeners that we created.

We are changing the configuration of the TraceListeners (the mapping of which category is mapped to which TraceListener) at runtime and then call Logger.Reset in order to load the new configuration.

In 4.1 this worked perfectly but when we migrated to 5.0 it suddenly stopped working. When we investigated the problem we noticed that after the call to Logger.Reset() the writer instance that is used by the Logger doesn't changed. (We checked by calling Object.ReferenceEquals(logWriterBeforeReset, logWriterAfterReset)).

We took at look at the source code, and narrowed it down to the instantiation of the LogWriter in the Logger class (LogWriter_get): in EntLib 4.1 the object was created through a factory that returned a new instance every time. In 5.0 the container is called, returning the same instance every time. (Probably has something to do with LoggerSettings.CreateLogWriterRegistration()).

(Also it should be noted that calling Logger.Reset causes the LogWriter to be Disposed, meaning that in 5.0 after calling Reset we'd be using a Disposed LogWriter.)

Is this the desired behavior?

If so, how do we set the logger to write to a specific TraceListener at runtime?



Jun 15, 2010 at 4:05 PM


I still need to verify if the Logger.Reset behaviour is by design or not.

Regarding "changing the configuration of the TraceListeners (the mapping of which category is mapped to which TraceListener) at runtime". How do you used to do this in 4.1?

I believe something like this would work in 5.0

            Configuration xmlConfiguration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
            LoggingSettings setting = (LoggingSettings)xmlConfiguration.GetSection(LoggingSettings.SectionName);
            TraceListenerReferenceData data1 = new TraceListenerReferenceData("Flat File Trace Listener 2");


                .Write("Test FFTL 2", "General");

And if ever the requirement may change to not having to utilize config files then I think using the Fluent Configuration API (http://msdn.microsoft.com/en-us/library/ff664363(v=PandP.50).aspx) will suffice that.

Gino Terrado
Global Technology and Solutions
Avanade, Inc.

Jun 16, 2010 at 2:23 PM
Edited Jun 16, 2010 at 2:32 PM
Hi, This is what we used to do in 4.1.

       LoggingSettings logConfig = OurCompany.ConfigurationManagerWrapper.Instance.LoggingConfiguration;
       NamedElementCollection<TraceSourceData> source = logConfig.TraceSources;
       sources.Get( categoryName ).TraceListeners.Clear();
       sources.Get( categoryName ).TraceListeners.Add( new TraceListenerReferenceData( listenerName );
       System.Configuration.ConfigurationManager.RefreshSection( LoggingSettings.SectionName );

This code is written in a special method we use for testing and its working when we use entlib 4.1. A few abbriviations: OurCompany.ConfigurationManagerWrapper is a special wrapper that enable us to add some logic to our configuration usage. We also have a configuration source that knows how to use OurCompany.ConfigurationManagerWrapper, so all the entlib classes recieve their configuration from what is assigned to ConfigurationManagerWrapper. In the tests we don't use configuration from a file, instead we are creating a LoggingSettings object and assign it to OurCompany.ConfigurationManagerWrapper.Instance.LoggingConfiguration.
Jun 17, 2010 at 10:49 AM


From your code snippet above, I haven't seen you have save your configuration after a new TraceListener was added and before the configuration was refresh. Try to save it in those lines and see if it works. Also, you can try adding some delay after the changes in the configuration is made during runtime because for what I know typically there are some delay before the changes to the config file will take effect in the running application

Anyway, I'm also unable to reproduce your scenario using EntLib 5 (with save), the changes in the Logger LogWriter take effect during runtime and it works fine in my end. 

Gino Terrado
Global Technology and Solutions
Avanade, Inc.