Check out the new video that introduces some basic concepts of the logging framework.
It's under 10 minutes!
The logging framework provides you with an easy means to log information to any destination. It comes complete with loggers that support writing to the system console, a file on disk, a TCP/IP socket, and more.
Instead of code like Console.WriteLine(ex); which will write basic exception information to the console, or
System.Diagnostics.Debug.WriteLine(ex); which will write to the Debug console, or even
System.Diagnostics.Trace.WriteLine(ex); which writes trace output, you could instead use code such as
Logger.LogError(ex); which can write to various consoles, and at the same time, write to a file, and even automatically send an email or a page to a support person.
The framework comes with loggers that can write to:
- a file on disk
- the Windows event log
- a TCP socket
- Console, Debug, Trace
Also included is a LogReceiverLogger, which can be used at the receiving
end of a socket. In fact, you can also download a small application that
subclasses this logger and use it to read your log entries from a remote
Click for larger image
And you can write to any and all of these different logs with a single call to a
CompositeLogger , which contains any number of other custom
loggers. There is also an InsistentLogger which you can use to wrap any
other logger. This logger will continually try to relog to its wrapped logger
whenever the wrapped logger fails to properly log. (e.g. You could wrap a
SerialSocketLogger with an InsistentLogger. Then, if the end receiving logs
over a socket happens to go down temporarily, the log entries will still get
logged once the receiver is back online.)
The framework has hooks for you to filter entries that get logged. For example,
you might want one log to write all information that it receives, but you could
reserve a support page log to handle only entries that are severe enough to
warrant a page. Also, you can filter entries based on the type of entry, or what
the framework refers to as a "category," which can be anything that you define,
or simply be a String. You could have a "database" category, for instance. A
logger could exist that handles only these database log entries.
There are also hooks in the framework for formatting log entries any way you
need. You can simply subclass one of the provided formatting classes and
instruct the logger to use your new formatter.
Your application doesn't need to distinguish between the various logs that it
might have. Once the logs are setup, your application can log everything it
needs to one central logger, knowing that there may be any number of other logs
being automatically notified with proper filtering and formatting.