(Note: I have seen several questions regarding .NET logging frameworks, but haven’t seen any which resembles our requirements. So please don’t close this one as a duplicate.)
We will need a logging framework for a highly distributed and parallel .NET application with the following features:
- It must be thread-safe, as log messages will be produced by many threads.
- Each log messages will need to have a timestamp. If the framework would add this automatically, that would make it easier.
- Besides a timestamps, there must at least be a severity/verbosity or something similar to attach to log messages, so that they can be filtered by it. More (orthogonal) predefined parameters (message source, intended audience, message kind, whatever…) to play with would be great.
- However, we need to add our own parameters anyway. The more these are treated like first-class framework citizens (can do the same with them as with the predefined stuff), the better.
- The framework should be able to filter messages based on at least the predefined parameters. We need to change filtering at whim during run-time.
- We need to put objects through this, not strings. Strings might be made from those objects in the end, but log message parameters must not be put into a flat string right from the start.
- Since some of the logging will be seen by customers, we might have to internationalize them. (Given that we want to log objects, not strings, this whouldn’t be too hard, but the more support the better.)
- We need to be able to write the log messages left after filtering into files and read those files back in. If the framework has the ability to stream the out and in, we don’t have to implement this ourselves.
- Each log message might be sent to several targets (file, window, remote machine) at the same time.
- If log messages have to be sent over the network, it might be necessary to do so in a dedicated thread.
- The thing will be used from C#.
OK, so we figure that it’s nigh impossible to find something out there that does all of this out of the box. These are just too many requirements, and probably too many uncommon ones.
But is there anything worth to use as a foundation and build our stuff upon?
AFAIK log4net does almost all of these. It’s mainly verbosity-level based for filtering, and though you can use
Filtersto filter using alternative criteria they’re not necessarily “first-class citizens”.Also, re. “reading the files back in” – I presume you don’t expect the logging framework to support this directly. Files are files, after all.