Logging and TransactionScope

We are using Enterprise Library 5.0 including the exception and logging blocks. We have run into an issue where using them within a TransactionScope during an exception will result in those logs being rolled back (database ones). Our solution is to wrap
the calls in a TransactionScope with a Suppress option so it does not participate in the ambient transaction and we retain all logs.

Is this the correct approach for this? Assuming that is the correct approach, we are looking for a solution that will allow our developers to use the EntLib Logger.Write(...) methods as vanila as possible and so were looking for the best way to abstract
this aspect. We "could" create our own wrapper around the Logger usage and do this BUT I don't like to introduce unecessary code and create many methods that just call the Logger.Write. So our thought is to create a custom LogWriterImpl deriving
from the one in EntLib and wrap the calls in the Suppress (maybe make it configurable from Unity). I think we can do this programmatically after EntLib has initialized its EnterpriseLibraryContainer.Current but am trying to find a solution where I can define
the replacement in a configuration file instead. Is this even possible?

If not, we will likely use an AppInstance.Initialize() method that all application would call in the infrastructure to manage these issues.

UPDATE: I noticed that we could inherit from LoggingSettings class that is the section for logging and possibly remove the programmatically set LogWriterImpl in favor of a configurable one during the GetRegistrations call. I will give this
a try when I get in to see if that works for us.

Thoughts?

NOTE: We may move the logging to MSMQ at some point so it reduces the processing time and would eliminate this (as long as we are not using transaction queues) but that is not in the current implementation.

Might I suggest that instead of replacing the LogWriter, you instead replace/modify the DatabaseTraceListener instead? You can put your transaction logic (or rather get-out-of-transaction logic) in there in the spot that's actually touching the database,
and the config tool picks it up since you are plugging in at a specifically designed extension point instead.

That would work for this scenario specifically and I will give that a try. We were also looking to intercept the logging at the point in time it writes
such that we could automatically inject (using unity) a collection of IExtra… (context suppliers but can’t remember the exact name) so that they could add the appropriate context at some point after Logger.Write but before sending to the listeners. Is there
another point at which this could be achieved so that all logs have that data without requiring the app developers to specify?

Might I suggest that instead of replacing the LogWriter, you instead replace/modify the DatabaseTraceListener instead? You can put your transaction logic (or rather get-out-of-transaction
logic) in there in the spot that's actually touching the database, and the config tool picks it up since you are plugging in at a specifically designed extension point instead.