Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Logging in APIs

Tags:

.net

logging

When I'm writing an API assembly for someone else to use, it would be useful to have some logging capability to help diagnose the clients' problems using it.

However, if I reference, for example, log4net in my assembly, this might clash with the version of log4net being used by the client's application.

I don't want to reinvent the wheel by writing my own logging framework.

What's the best way to solve my dilemma?

Edit: I suppose I could demand that the particular version of log4net I am using be installed into the GAC to avoid the version clash with the client, but that would make the API a fat thing that requires installation instead of a drop-in assembly.

like image 209
Matt Howells Avatar asked Jul 09 '09 15:07

Matt Howells


3 Answers

Look at how SpringFramework solves this problem. It uses Common.Logging which can then be mapped to log4net or to any other custom logging framework via the config file. You can find more details on the Common.Logging website but basically you do the following:

  • reference Common.Logging in your class in use it just like log4net
  • the consumer of your framework will configure Common.Logging to use log4net like so:

  <configSections>
    <sectionGroup name="common">
      <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
    </sectionGroup>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
  </configSections>

  <common>
    <logging>
      <factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
        <arg key="configType" value="INLINE" />
      </factoryAdapter>
    </logging>
  </common>

  <log4net>
.... normal log4net configuration goes here...
  </log4net>

If the client is also using SpringFramework or the Common.Logging directly, the conflict is still possible but its odds are greatly decreased for the following reasons:

  • Common.Logging team is thinking hard to ensure backward compatibility of future versions with past versions. For example 2.0 is fully binary compatible with 1.2.
  • Common.Logging changes less frequently than log4net, at least in theory
like image 165
Stop Putin Stop War Avatar answered Oct 10 '22 20:10

Stop Putin Stop War


Use the Enterprise Library. It's flexible enough, and uses both built-in loggers and its own. It has been fairly verison-compatible as well. It's configurable enough that if there were a conflict with a particular component, you could easily swap it out, with just configuration changes.

like image 43
John Saunders Avatar answered Oct 10 '22 20:10

John Saunders


Use System.Diagnostics.Trace. No chance of version clashes then!

like image 24
Matt Howells Avatar answered Oct 10 '22 22:10

Matt Howells