Fast and comprehensive logging tool for .NET applications
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
ConsoleDemo
FieldLog
FieldLogViewer
LogBenchmark
LogSubmit
LogSubmitWebPhp
OSInfoTest
PdbConvert
Setup
SmoothListTest
WinFormsDemo
_scripts
img-src
.gitignore
FieldLog.FxCop
FieldLog.sln
LICENSE-GPL
LICENSE-LGPL
README
Settings.StyleCop

README

About FieldLog

Website: http://unclassified.software/source/fieldlog

FieldLog is a fast and comprehensive logging tool for .NET applications. It allows applications to write events, data and errors to managed and efficient log files. The logging methods are optimised for high performance multi-threaded operation and a single log method call takes as little as half a microsecond on modern hardware. There's no comparison to OutputDebugString, Debug.WriteLine or appending to a file each time! This logging can be used in performance-critical loops without noticeably slowing down the application.

ALWAYS-ON LOGGING

The general idea is to always leave debug logging enabled to be able to analyse it in case of an application failure. Traditional log systems can only append to log files but never delete old data. This leads to constantly increasing log size with the debug level enabled. FieldLog can manage its log files and only keep items of each priority for a specific time, then delete it to save space and remove unnecessary data. The low latency and good storage efficiency allow you to keep logging enabled. When an error occurs, all the relevant information is already here to be analysed.

You don't need to instruct your users to enable logging by tinkering with hidden XML files and wait for the error to happen again. Instead, the user is guided through collecting the relevant logs and submitting them directly to the developer.

FILE COMPRESSION

The log items are written in a binary format that minimises the amount of bytes per information and reuses any previous text strings for storage efficiency. If the same message string is logged over and over again, it will hardly increase the log size. The files are separated by log priority and a new file is started after a certain file size or time. If available, NTFS compression is used and considered in file size decisions. Old log items are automatically deleted. The maximum log size and keep time is configurable by an easy to understand and robust text file in the application directory.

LOG VIEWER

The log viewer application, FieldLogViewer, loads a set of related log files and displays the log items in a list. The user can select any item to view all the details like thread ID, additional exception data, stack traces or system environment data at that time. Items are colour-coded by their priority and icons display the type of event.

A powerful filter editor allows you to quickly find the interesting events and concentrate on what matters. The viewer can even keep reading at the end of the log files and show new log items as they are written by the running application. This allows a developer to monitor the application in real-time. The selected filter remains in effect.

You can also use FieldLogViewer as a DebugOutputString listener (like Sysinternals' DbgView) and read limited debug output from other processes as well.

SUBMIT TOOL

An easy to use log sumit tool guides the user through the process of selecting the relevant log files, packaging them for transport and choosing a suitable transport method. The transport methods are currently sending an e-mail and copying the package to a local directory like a USB flash drive. Future methods are using an HTTP or FTP server and sending to Bluetooth devices. This tool can be started in response to an unhandled or unrecoverable application error (crash reporting) so that the user is prompted with the right information and can submit trace logs while they're fresh.

REQUIREMENTS

Any version of Microsoft Windows supported by the .NET framework should do. The WPF-based FieldLogViewer application likely requires Windows XP or newer.

The Microsoft .NET Framework 4.0 Client Profile is required for complete support of all packages. If your application is targeting .NET 2.0, you can still use the FieldLog assembly in your project to write log files. The log submit tool is currently also planned to support .NET 2.0 as well. So you can deploy FieldLog with your .NET 2.0 project but need .NET 4.0 to view the log files.

The solution and project files are created by Microsoft Visual Studio 2010 SP1. Any edition (Professional, Premium, Ultimate) should do. Newer versions of Visual Studio use the same file format so you can seamlessly work with the solution in Visual Studio 2012/2013 as well.

The setup is built using InnoSetup. It requires the InnoSetup preprocessor which is included in the Inno Setup QuickStart Pack. Version 5.5 has been tested to work.

The build script is implemented in PowerShell and has been tested with PowerShell 2.0 and 3.0. Older versions may fail. The build script searches the registry and other available sources to find the .NET build tools, InnoSetup, Git and other required tools. It works on 32 and 64 bit systems (though it's only really been used on Windows 7 64 bit systems).

BUILDING

This software is built mainly with standard Visual Studio tools, automated with the PowerShell build framework.

There is a number of entry scripts for the automated build process. These scripts are located in the "_scripts" directory and starting with "build". The scripts start the common build script with certain section names that are pretty much described by the file name. "build_release.cmd", for example, builds the solution in the Release configuration and "build_release_setup.cmd" additionally creates a setup executable in the "Setup\bin" directory. The assembly and setup version are determined from the currently checked out Git revision.

It is also possible to open the solution file in the repository's root directory with Visual Studio and work with it as usual. You probably need to unload the projects "FieldLog.NET20" and "FieldLog.ASPNET40" first to avoid compiler confusion. To create the setup executable, you need a current version of InnoSetup (use the Unicode Inno Setup QuickStart Pack download).

THE NAME

The name "FieldLog" was originally supposed to refer to "out in the field logging" which is where your applications run. It does everything it can to maintain itself out there and to provide the developer with all relevant information about any problems that might occur. The developer does not need to go where the application runs if users have sufficient internet connectivity or remote hands to submit logs and install updates.

Another interpretation might refer to the structured log items that distinguishes FieldLog from plain text log files that actually only store a single line of raw text about each event. Being able to access and understand each bit of information allows for filtering the data masses to actually see the interesting parts.

The logo merges the capital letters F and L into a combined shape (which happens to look like an E), using different colours for the parts distinct from both letters and the shared part. The horizontal bars also depict "good" and "error" rows in a log list, which is basically what you can see with FieldLog.

LICENCE

The FieldLog library, which is used in applications, is released under the terms of the GNU Lesser GPL (LGPL) licence, version 3.

The other projects (FieldLogViewer, demos and tools) are released under the terms of the GNU GPL licence, version 3.

You can find the detailed terms and conditions in the download or on the GNU website <http://www.gnu.org/licenses/lgpl-3.0.html> and <http://www.gnu.org/licenses/gpl-3.0.html>.