Shutting down log4net repositories

I’ve been learning and evaluating the Gibraltar ‘Runtime intelligence’ & logging application recently. If you’re already using log4net, there’s a very low impact route to adopting its many benefits by using their simple Gibraltar Appender.

In knocking up a quick sample application to test, I had setup and configured my Log4Net logger:

public class Program
  private static readonly ILog Log = 
  static int Main(string[] args)
    if (!LogManager.GetRepository().Configured)

The simple application went on to output some simple log lines to test using the Gibraltar appender. All was fine, except this simple console application appeared to hang on exit. I quit the running application and Gibraltar dutifully announced that my session had Crashed.

A bit of headscratching later made me realise that I needed to be a better Log4Net citizen in my sample application. I had omitted the line:


Now my code properly stopped its logging activities before the program exited and Gibraltar was able to report successfully. The Log4Net RollingFileAppender or ConsoleAppenders don’t complain like this on program exit if the repository isn’t shutdown first but it does makes sense to tidy up after yourself rather than relying on the garbage collector.

I’ll write more about my positive experiences of Gibraltar in another post, but just wanted to share this in case any early adopters faced the same ‘facepalm’.

TDD, Visual Studio 2010 & BadImageFormatException

Just had a very strange run-in with Visual Studio 2010 throwing a BadImageFormatException. Just to set the scene I’ve got Visual Studio 2010 running on a Windows XP 64-bit machine.

My solution has a Console Application and a few Class Libraries; one of which is for Integration Tests using StoryQ and another which is for my unit tests classes.

Running my Console application works fine on its own, but as soon as I either ran the Unit Tests or got Resharper to run my Integration Tests, I was hitting a BadImageFormatException. It could not load my console application (or one of its dependencies).

A bit of blog searching found an forum thread which talks about how a new c# console application targets x86 by default. I think the combination of it attempting to run my console application in x86 and my test libraries on the 64-bit environment was causing a battle of wills.

The solution is to go into your console application Properties and switch to the Build tab. Then make sure that for both Debug and Release configurations that your Platform Target is set to “Any CPU” rather than “x86”.

This then allows your TDD to continue unchallenged by assumed defaults and the use of a 64-bit OS.