I have just finished going
through my code and replacing my own logging code with NLog in some of my
infrastructure code for the next release of a software project I run (http://d20spellbook.home.comcast.net).
I have a few comments I would like to pass along.
It would be nice if the
Logger.XXXException methods had an overload that allowed for formatting the
output message, i.e.:
e, string format, params object args);
I had this in my own logging
code and going through all of the places where I caught exceptions and
effectively changing 1 line of code (the log entry) into 2 (1 to build the
string and 1 to log it) was mildly annoying.
My product has many
assemblies, ideally I would like to keep NLog references out of all of them but
1; isolating the NLog code behind my own wrapper to minimize the impact of any
changes made to NLog and to allow migration to some other logging system if it
ever became more appropriate. The problem with doing that as the code is now
constructed is the stack tracing, my log wrapper class would always show up as
the type that generated the logging statement.
What would be really nice is
if the LogManager provided a factory method like the following:
name, Type wrapperType);
Where wrapperType would be
the type of the class used to wrap NLog. This would have to be pushed down to
the Logger type, and it would need to ignore both its type and this type when
performing the stack trace.
This would allow someone to
wrap NLog to isolate it yet still provide the correct signature information for
the log entry.
A suggestion I would make
(although it doesn't really matter in the short term) would be to place all of
the logging business logic into an interface and change the LogManager to
return interface references instead of object references. This would open the
door to all sorts of possibilities in the future.
I do have to say I am very
impressed with the configuration, it is both simple and powerful and was one of
the primary factors in my decision to switch to NLog.