LogNut is a comprehensive logging facility written in C# for C# developers.
It serves the (ideally) very simple purpose of providing a way, within your own code, of writing a piece of text somewhere where you can see it,
and thus know what is going on within your code.
It is intended as an alternative to such as Log4Net or NLog, although it is at this point much younger and less mature that those excellent products. This will change as we near the completion of 2012: LogNut will provide more capabilities, be easier to use,
and apply to more platforms.
Each separate output from a logger is called a "log-record" (my mind is open to alternatives! ?)
Each log-record has an optional prefix which exists for the purpose of providing meta-information for that log-record. This meta-information is configurable and may contain a timestamp, hostname, logger-name, and level.
The portion of each log-record other than the prefix, that is - the actual content, as it is shown within the viewer - is called the log-message.
A "Trace" is a rendering of a log-record on-screen. Thus, to delete a trace means to remove it from the screen but not necessarily to delete that log record from whatever persistence store is being used.
The term "Windows Event Log" is always used when referring to that specific facility, to avoid confusion.
The version numbers used by this library follow the Semantic Versioning Standard (see
Tom Preston-Werner's excellent paper).
- Windows XP, Vista, 7, 8, Server 2008, Server 2012, x86 and x64
- Windows Phone 7, 8
- Linux (using Mono)
- Visual Studio 2008 solution using .NET 3.5
- Visual Studio 2010 solution using .NET 4.0
- Visual Studio 2012 solution using .NET 4.5
- F# (via .NET interoperability)
- Android via Xamarin Mono for Android (C#)
- iPhone via Xamarin MonoTouch (C#)
- Microsoft Visual C++ native
To test/verify the compatibility of LogNut with these platforms, I am currently setting up the following VMware virtual machines (hereinafter referred to as VMs). I am selecting these to provide a test-matrix that is sufficiently complete such that any failure
that would surface due to the choice of platform would show up within at least one of the automated builds or tests that are run against each of these VMs:
("SP" = Service Pack, x86 = 32-bit, x64 = 64-bit) :
Windows 7 Ultimate x64
Windows 7 Ultimate x86
Windows 7 Home Basic x86
Windows Vista Ultimate SP2 x64
Windows Vista Ultimate SP2 x86
Windows Vista Ultimate SP1 (to verify VS 2010 build correctly indicates need for SP2)
Windows XP Professional SP3
Windows XP SP2 (to verify VS 2010 build correctly indicates need for SP3)
Windows Server 2012 Essentials
Windows Server 2008 R2
Windows Server 2008 SP2
Windows Server 2008 Service-Pack 1 x64
Windows Server 2003 R2
Windows Server 2003 (to verify VS 2010 build correctly flags need for SP2, MSXML6)
Ubuntu 12.10 x86
Ubuntu 12.10 x64
(Q: Do we care about earlier versions of Ubuntu?)
As part of my general push to make 'things that just work', LogNut is going to have a means for installing it automatically, as part of a PowerShell command that can be invoked explicitly or as part of an automated build process. This means that a NuGet
package will be created for LogNut, plus provision for invoking this functionality via a simple PowerShell call.
I have been extremely frustrated with the experience of loading up a project (often when I arrive at some client location to begin work on their stuff, but also just from trying out someone's opensource library) -- and it does not build. Only to find
that some dependency is not present, and I have to discover this via much drilling down and clicking, and then make guesses at where to get that external dependency, which version to get, and whether to run its installer or just copy some DLLs, or whatever.
This is a pain. It's a distraction. And it leaves one with the definite feeling that someone did not do their homework. That is not an impression I want to give others of myself or my team.
The purpose of a build script is to build something automatically. This ought to include fetching whatever it requires to accomplish that build. If it absolutely
cannot, then a quick, explicit, clear alert should be provided to the user. If it can reasonably figure out how to accomplish that build, then it should do so with a minimum of fuss.
NuGet is one solution that already exists, is popular and well-supported, thus I will make use of it first. But also, I want to provide a solution for those corporate (or home) environments where an online connection is NOT present. These are
important too! For this, I'll define a standard means of sharing a storage location on the local filesystem, or else somewhere on a shared LAN location. There must be a well-defined protocol, a way of specifying the standard place to find the information that
says where to find stuff, and a way to actually go to that dependency, choose which version to get, and fetch and install it -- and then continue on with the build process.
As part of this requirement, LogNut will need not only a way to be installed via PowerShell, but also to be managed and called via PowerShell.