Re: Newbie: Log4Net or MS Logging Application Block?

[Mike Liddell]

I am not a log4net expert... so please consult others too and do your own investigation. :: Category vs. log4net filtering - Category is a flat filter rule.  log4net hierarchy is much more powerful.  for additional filtering on other attributes, add info to the properties and/or stacks and filter on them. - Only use named properties where they are globally relevant as you have to type them verbatim into your configs. - Use a generic property bag otherwise, eg Property{Tags} rather than Property{TagA} + Property{TagB} Important notes:  - for adding custom properties and stacks that are simple data, not thread-state etc, you must avoid using the ThreadContext approach even though it is the obvious first attempt. It is incredibly slow. eg 10K logs/second rather than say 1million logs/second.  rather, use a wrapper that performs log.Logger.Log( manualLogEvent). - also, follow the pattern of creating a static Logger instance once per unit (and their recommendation of one per class seems sound and that is what I am using).  it is far too expensive to instantiate a Logger for every log() call.  I personally have my own wrapper object that includes a Logger instance and I create a static one of those per code class.  I am budgeting about 100bytes per instance at, say, 10K classes max for 1MB working set usage. I'm not sure if this is accurate. - use Text or Property filters to perform filtering on your custom property :: MSMQ I don't currently have a need for MSMQ appender.  I expect someone already has made it.  If the EntLib one is not too tricky, you would be able to reproduce it quickly by extending AppenderSkeleton. :: Async Log4net is synchronous too.  I'm not sure if there is asynch for normal targets. hope it helps, Mike. shaeney wrote: OK, that very good information. I see that the MS Logging Application Block (LAB) allows messages to be routed based on "Category" and each message contains a collection of name-value pairs of meta data. What is the corresponding Log4Net technology? From what little I have seen, messages are routed based on Class Type? I think that LAB is synchronous by default, with asnyc comms achieved via MSMQ, but Log4Net is async by default? Cheers, Steve Mike Liddell wrote: For my purposes, Log4net is better in every respect. I wish I knew this two years ago. I am the architect for a medium-sized distributed project that is perhaps in the 200-300K lines category. We started with EntLib logging but never really enjoyed it - the configs and the lack of built-in filtering options was limiting. During a recent comparison I also found the logging generation rate (eg max number of calls to Logger.Log() can be made, particularly when the messages are being filtered out and not delivered anywhere) is unexpectedly slow. To cut to the chase, I did a full side-by-side comparison and decided to ditch entlib logging in favour of log4net without any hesitation. The primary considerations were: - log generation rate. the raw speed of log4net is excellent - hierarchical logging. and well implemented too. - cleaner, much more extensible and obvious config format - easier programmatic extensibility - more built in log targets (ie the standard appenders) - generally a much more _professional_ library. Entlib is a good idea. Every time I use log4net I am happily surprised. cheers, Mike Liddell shaeney wrote: Hello all, I have been asked to compare the Log4Net library with the Microsoft patterns & practices Logging Application Block. I have searched this forum but can't find anyone who has asked this question previously. I would have thought this is a common topic. Does anyone know if this type of side-by-side comparison has been done? I know that both are very extensible, but I am interested in comparing the core deliverables. In particular, I am interested in using either for both Logging and Auditing purposes. Audit will require transactions, which is to say that the calling code needs to know if the Audit message has been persisted or not before it can continue. Cheers, Steve