Logging is one of those things where once you have it, you never really pay much attention to it. Today I decided to investigate what is new in the logging world since the last time I looked at it. I heard of NLog some time ago, but never took the time to test drive it. In the past I have always used log4net, so I decided to compare NLog to it. Here are some of the things that I really like about NLog, and it might not be possible or “easy” to do with log4net:
NLog provider wrapper and compound targets for asynchronous processing, loading balancing, buffering, and etc.
The configuration file structure is simple and easier to write. If you do not remember all the options, no worries, you will receive Intellisense in Visual Studio.
You can split up the configuration to multiple files by using the <include />.
Like all other logging frameworks, NLog is able to add contextual information when each message is logged. You can use the contextual information to create a log file for each user, create one log file per day, one file per logger, or any combination. Stack trace can also be included when each message is logged.
Not Swallowing Exceptions:
Sometimes it is useful to know when the logging framework is throwing an exception to prevent logging from happening; NLog can be configured not to swallow any exceptions. It is useful to troubleshoot problems during deployment.
Defining Variables in Configuration File:
Common value can be stored in a variable. Great way to keep you configuration file DRY.
Note: This is a superficial look at some of the features of NLog, and I have not worked with NLog extensively.