Logging from a class library?

Topics: Logging Application Block
Apr 25, 2007 at 4:30 PM
I have a class library that uses logging, and that is working well as it picks up the app.config from the containing application. However if the consuming application is not configured with the "Logging" section I get an exception thrown indicating I am missing the section. Which all makes 100% sense, the only way I can see how to avoid the exception being thrown is to wrap all logging within the class library in something like:

 if (null != ConfigurationManager.GetSection("Logging"))"
  // Perform logging here

Is there a better way to allow users who want the functionality of the class library, but perhaps do not want to configure up the EL sections. Or is it a fair assumption each application is mandated to add and maintain their own logging? I presume a half way house would be to allow the consuming application to provide a reference to the configuration provider with the configuration in then everything works as expected.

Has this been addressed before, or are most implementations standalone apps?

Many thanks,

Apr 25, 2007 at 7:18 PM
Hi Gareth -

You have a few options here:
  1. Require the host application have a valid logging configuration file
  2. Use an alternative configuration source (such as a FileConfigurationSource or DictionaryConfigurationSource) that is "owned" by the class library instead of the host app. You will need to code to the LogWriter class instead of the Logger façade to use a non-default configuration source
  3. Use code similar to what you described above, or update the logging block code to degrade gracefully (assume defaults or do nothing) if no configuration is present.
Hope this helps
Apr 25, 2007 at 8:28 PM

To me I think the most extensible (and correct) solution is option 2, this allows the configuration to remain separate and 'patchable' (configuration separated from application). Option 1 is probably the short term answer :-). Option 3 is messy both ways so I'm hoping to avoid anything to do with that! Option 3 got me out of the short term bind - but to me there are too many drawbacks unless it is built into 'base' EL.

I have one follow on curiosity question (that doesnt directly affect me now - but I'm interested). If the host application uses EL, but not using the 'base' EL (a custom strong named version) and the class library is using the 'base binary' can the two co-exist? Or in that scenario would the class library need to be built against the custom version of EL in order to be successfully used within the application?

It certainly does help - and hopefully will help others too!

Apr 25, 2007 at 8:56 PM
Hi Gareth -

I believe it's possible to do this kind of thing, but there are some caveats. From my experimentation (I can't recall having read anything in the docs about this), it is possible to load 2 different versions of the same assembly into the same AppDomain, provided they are loaded from different places or are both in the GAC. However it isn't possible to reference more than one version of the same assembly from any given assembly, nor can you use a "using" statement or anything similar to ask for a specific version of an assembly - so you need to partition code that uses different versions of the same assembly into their own assemblies.

Since this probably doesn't make sense, I mean something like this:
      B.dll -> D.dll v1
      C.dll -> D.dll v2 
This approach should allow you to use two versions of the same DLL in one AppDomain provided you isolate the code in a similar way.

Apr 25, 2007 at 9:12 PM

So it sounds completely viable to run two instances together. However I dont intend to find out in the near term (and am hoping I dont run in to it either!) :-)

Many thanks for the fast turn around (and nice graphics!),