Exception Logging and EntLib 5 External Config File

Topics: Exception Handling Application Block
Dec 29, 2010 at 5:15 PM

I'm using EntLib 5 logging, validation, and exception handling blocks in a new C# application (also using Prisim). Recently I moved the EntLib configuration out of app.config and into its own "entlib.config" file that will be shared by all users. All the EntLib features I use have been working until today when I tried to use the Exception block for basic exception logging.

Actually, the exception logging does work if I use the static ExceptionPolicy class -- like so:

ExceptionPolicy.HandleException(ex, "Default Policy");

It also works as expected when using the ServiceLocator to get an ExceptionManager instance:

ExceptionManager exMgr = EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>();
exMgr.HandleException(ex, "Default Policy");

But exceptions don't get logged if I use constructor dependency injection (Unity) to get an ExceptionManager instance.

public class MyClass
{
    private ExceptionManager _exMgr;

    public MyClass(ExceptionManager exMgr)
    {
        _exMgr = exMgr;
    }

...

    // Later in a catch block

    _exMgr.HandleException(ex, "Default Policy");

The class constructor receives an ExecptionManager instance, but when it's used to call HandleException(ex, "Default Policy"), nothing (obvious) happens -- in particular, nothing gets logged. Even though it's using the same external config file and "Default Policy" as the working cases.

Is there a problem with DI ExceptionManager instances accessing external configuration files?

Thanks,

Jim

Dec 29, 2010 at 7:26 PM

Additional information:

Turns out the DI injected ExceptionManager is logging the exceptions, just to a different file than the other log messages. My logging configuration uses fileName="P:\app\logs\%USERNAME%_%COMPUTERNAME%_trace.log" to specify the log file location. The first two (working) examples of exception logging in the above message write to this log file (as do all the other non-exception log messages). But the DI injected ExecptionManager is pre-pending a GUID to the log file name.

So for example, where most logging output goes to "P:\app\logs\jimm_WIN7JIMM_trace.log", exceptions are written to "P:\app\logs\19c401c-f593-40c0-b800-4495b86b7a17jimm_WIN7JIMM_trace.log". It seems to use a new/different GUID for each exception.

Why is a DI injected ExceptionManager adding a GUID to the log file name and how do I make it stop? 

Thanks again,

Jim

 

 

 

 

Dec 29, 2010 at 10:02 PM

Note to self...

A web search for "enterprise library" +guid +exception +logging turned up quite a few hits. Apparently the guid prefix can happen if the log file is locked.

I'm still not sure why this would only happen when using constructor injection to get the ExceptionManager instance, but it does.

For now I can avoid the guid "enhanced" log filenames by configuring a logging category & listener just for exceptions.

Dec 30, 2010 at 2:39 AM

Glad to hear you're able to get through this :o)

Anyway, not sure if may still help but here's a related thread - http://entlib.codeplex.com/Thread/View.aspx?ThreadId=228089

Gino Terrado
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com