Termite Logging Framework for .NET termite VS Tool online logging
tweet tweet tweet tweet tweet


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.

class diagram

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
  • memory
  • email
  • 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 location!

log receiver application
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.