EntLib 4.1 bug in Logger w/Unity?

Topics: Logging Application Block
Nov 19, 2008 at 9:06 PM
Looking at the quickstart samples:

The tracing sample without unity (new Tracer()) correctly displays LoggingQuickStart.QuickStartForm.traceButton_Click
as the start method of the trace.

The unity version of the quickstart displays Microsoft.Practices.EnterpriseLibrary.Logging.TraceManager.StartTrace
as the start method of the trace, when the traceManager.StartTrace method is used?

Am I missing something?

thx


Nov 20, 2008 at 2:23 AM
Looking at the source code, the StartTrace method basically just initializes a new Tracer object.  The difference is that it passes the associated LogWriter and TraceInstrumentationListener when creating the Tracer object.  If you want to use your own LogWriter instead of the static Logger class, you can use the StartTrace method.   The creation of the TraceInstrumentationListener (if your TraceManager's associated TraceInstrumentationListener  is null) is also different for the 2 constructors. 


Sarah Urmeneta

Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com

 

Nov 20, 2008 at 1:38 PM
Edited Nov 20, 2008 at 2:04 PM
The documentation says that if unity is being used, the TraceManager facade should be used to create the Tracer.

However, if the TraceManager facade is used, the start method of the Trace is always "TraceManager.StartTrace"

Isn't that a bug?  I'm just looking at the Quickstarts here, one uses Unity and the other does not.  They have different behaviour.


Edit:  I should also add that while the TracerEnter method name is always StartTrace() the TracerExit method name is correct.
Nov 20, 2008 at 4:23 PM
I have since found this article, written for v2.0 but still applicable here:
http://www.codeproject.com/KB/architecture/EntLibLoggingExtended.aspx

In the article, he updates the Tracer.cs file from this:

if (method.DeclaringType != GetType())

to this:

if (!typeof(Tracer).IsAssignableFrom(method.DeclaringType))


The author explains that this change supports creating subclasses of the Tracer class, and have the Tracer report the correct method name, by ignoring items on the call stack that inherit from Tracer.

I think some combination of these changes to:

a) fix the TraceManager
b) support use of sub-classing the Tracer class

might be a good idea?





Nov 20, 2008 at 10:38 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.