log4net logging UnhandledException exceptions from different projects

Question

I have several projects in my solution, most of which are windows services. I have log4net configured for each (generating a separate log file for each), as well as Raygun appender for log4net. I would like to catch UnhandledException for each of these projects and have info of where they originated from (both in the log file and raygun dashboard), and I would like to do this in one place for all projects in my solution.

Thus, I created a separate static class and method that would log those exceptions.

• How can I log an exception so that my log file would show the class that generated that error and NOT the Logger static class (as well as have raygun.io dashboard show proper origin of the exception) =>

  Logger.UnhandledException [ERROR]- this is now wrong. it should be class name of where the exception originated

• Would I create a thread safe singleton for this? Is this even the right approach?

Static class:

public static class Logger
{
    private static readonly ILog Log = LogManager.GetLogger(Assembly.GetEntryAssembly().FullName);

    public static void UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Log.Error(e);
    }
}

Windows service:

private static void Main(string[] args)
{

        Configure.Serialization.Xml();

        // Unhandled exceptions - subscribe to the event (I would do this to all my projects in the solution)
        AppDomain.CurrentDomain.UnhandledException += Logger.UnhandledException;
}

Answer 1

There's no way to get the class name for where an unhandled exception occurred, except perhaps by using reflection on the stack in the event handler, which in a release build isn't guaranteed to give you the class name anyway.

Unhandled exceptions should be exceptional in a Windows service with proper error handling: wrap your Main code in a try..catch clause, and catch exceptions wherever they may happen in the service code. If unhandled exceptions still occur, you will at least have a stack trace to work with, which will allow you to identify where the exception came from.