Thursday, January 06, 2005
C#/.Net Logging
I went looking for a good C#/.Net logging (Logger) library to use on a home project. I found two main ...options, Apache’s log4net and one on Sourceforge called NLog. Both looked pretty well developed. I also noticed Microsoft’s Logging Application Block, but it’s apparently heavyweight in the extreme, requiring Microsoft Enterprise Instrumentation Framework. I don’t know much about it, and decided the odds I’d use it are so low as to make it not worthwhile to learn about it.
I took a look at log4net next and didn’t like some things:
1. Version 1.2.0 has been in beta for 2 years. That’s not a good sign for its speed of development. Logging is such that once you pick a package, it’s potentially really painful to change later. I want to pick a winner right from the start.
2. It doesn’t have an interface like log.Info(string format, params object[] args). I really can’t understand that, and find it very irritating. I understand that it’s common to log exceptions, but I bet 99% of the log statements I’ve written in the past do not have exceptions to pass. It’s frustrating that people have put so much effort into the development and there’s a deal-killing issue like that in it for me.
3. Looks like it can’t do run-time programmatic configuration easily, which is important to me.
My use pattern in the past has required modifying the verbosity at runtime. The two scenarios that come to mind are:
1. a command-line program that has arguments to determine verbosity
2. a service that has diagnostic client that can connect and set the verbosity.
On the other hand log4net looks like the largest and most fully developed library available.
I got NLog and wrote a test program. It took about an hour to get going for various reasons (I don’t list these to be critical, I list these to be helpful to other people):
1. The version I downloaded (0.2 beta 1) had a bug with appender list "console,file" where it only sent output to the file. It took a few minutes to find out I should get the latest snapshot and where to get it.
2. The snapshot I downloaded (20050104) had InternalLogger.LogToConsole = true regardless of the config file value. That took a few minutes to figure out.
3. No default config. If you just create a Logger and try to use it you get no output because there isn’t a usable starting configuration. So this produces no output:
Logger log = LogManager.GetLogger("MyLogger");
log.Error("This is an Error statement.");
It’d be a little faster to get going if it did. You have to get an App.config or explicitly load a log file to get a configuration that displays this output.
But after getting a .nlog and then an App.config going it worked well.
Now I’ve got these issues with NLog:
1. I realized that due to the structure, where rules point to appenders, it won’t be easy to modify verbosity threshold programmatically at runtime.
2. Verbosity apparently isn’t handled as a threshold, which is different from what I’m used to. I would normally expect a single threshold value. Instead NLog takes the more flexible (and therefore necessarily more complicated) approach of allowing you to turn off Warn messages while seeing Debug, Info, and Error messages. I don’t think this complexity/flexibility tradeoff is a good call.
3. No log file rolling appender yet.
Arrrrrghhhh… I’m going to use my way-too-simple RTools.Util.Logger class, and probably have to enhance it gradually as I need more capability. Painful. Fortunately my Logger API is similar to NLog’s, so maybe I’ll be able to switch to NLog later fairly easily.
I took a look at log4net next and didn’t like some things:
1. Version 1.2.0 has been in beta for 2 years. That’s not a good sign for its speed of development. Logging is such that once you pick a package, it’s potentially really painful to change later. I want to pick a winner right from the start.
2. It doesn’t have an interface like log.Info(string format, params object[] args). I really can’t understand that, and find it very irritating. I understand that it’s common to log exceptions, but I bet 99% of the log statements I’ve written in the past do not have exceptions to pass. It’s frustrating that people have put so much effort into the development and there’s a deal-killing issue like that in it for me.
3. Looks like it can’t do run-time programmatic configuration easily, which is important to me.
My use pattern in the past has required modifying the verbosity at runtime. The two scenarios that come to mind are:
1. a command-line program that has arguments to determine verbosity
2. a service that has diagnostic client that can connect and set the verbosity.
On the other hand log4net looks like the largest and most fully developed library available.
I got NLog and wrote a test program. It took about an hour to get going for various reasons (I don’t list these to be critical, I list these to be helpful to other people):
1. The version I downloaded (0.2 beta 1) had a bug with appender list "console,file" where it only sent output to the file. It took a few minutes to find out I should get the latest snapshot and where to get it.
2. The snapshot I downloaded (20050104) had InternalLogger.LogToConsole = true regardless of the config file value. That took a few minutes to figure out.
3. No default config. If you just create a Logger and try to use it you get no output because there isn’t a usable starting configuration. So this produces no output:
Logger log = LogManager.GetLogger("MyLogger");
log.Error("This is an Error statement.");
It’d be a little faster to get going if it did. You have to get an App.config or explicitly load a log file to get a configuration that displays this output.
But after getting a .nlog and then an App.config going it worked well.
Now I’ve got these issues with NLog:
1. I realized that due to the structure, where rules point to appenders, it won’t be easy to modify verbosity threshold programmatically at runtime.
2. Verbosity apparently isn’t handled as a threshold, which is different from what I’m used to. I would normally expect a single threshold value. Instead NLog takes the more flexible (and therefore necessarily more complicated) approach of allowing you to turn off Warn messages while seeing Debug, Info, and Error messages. I don’t think this complexity/flexibility tradeoff is a good call.
3. No log file rolling appender yet.
Arrrrrghhhh… I’m going to use my way-too-simple RTools.Util.Logger class, and probably have to enhance it gradually as I need more capability. Painful. Fortunately my Logger API is similar to NLog’s, so maybe I’ll be able to switch to NLog later fairly easily.
# posted by Ryan @ 3:04 PM 
Subscribe to Posts [Atom]