¿Cómo diferenciar entre llamadas Trace y Debug en un escucha de seguimiento personalizado?

Question

Trace.Listeners y Debug.Listeners están compartiendo la misma colección interna por lo que no puedo agregar un detector de rastreo a Trace.Listeners y un oyente de depuración a Debug.Listeners para diferenciarlos.

¿Cómo puedo lograrlo?

Editar:

¿Por qué quiero hacer esto es simplemente porque estoy wrting una capa de registro a nuestra aplicación y quiero hacer un seguimiento de los diferentes registros en todo el sistema en el que Depuración/Trace es dos fuentes de registros (hay un par de otras fuentes también) Quiero hacer un seguimiento de.

Answer 1

[EDIT]

me perdí la parte en el título de la pregunta donde se menciona que esto en el contexto de una escucha de seguimiento personalizado. Por lo tanto, aparentemente ha escrito (o desea escribir) un TraceListener personalizado que podría diferenciar entre Trace.WriteLine y Debug.WriteLine. Creo que todo lo que digo a continuación sigue siendo cierto en cuanto a que TraceSources es preferible a Trace.WriteLine y Debug.WriteLine. Sin embargo, mi respuesta no necesariamente responde a su pregunta, excepto para decir que no creo que sea posible desde los métodos Write y WriteLine de un TraceListener decir si fueron invocados finalmente debido a una llamada a Trace.WriteLine vs Debug .Línea de escritura.

No está claro lo que está tratando de lograr, incluso si desde dentro del TraceListener personalizado puede distinguir la fuente de llamada final de Write o WriteLine. Sea lo que sea que quieras lograr, tengo que creer que sería más fácil hacerlo si, para empezar, basaste tus declaraciones de registro en tu código en TraceSources.

Podría agregar algún código a su pregunta original que muestre cómo puede escribir algún código de aplicación, agregando algunas llamadas a Trace.WriteLine y Debug.WriteLine. Además, muestre algún código de su TraceListener personalizado que muestre qué acción desea realizar si PODRÍA distinguir entre Trace.WriteLine y Debug.WriteLine. Algo así como:

public void WriteLine(string msg) 
{ 
    if (WasWrittenFromTrace) 
    { 
    //Before writing to output, add "TRACE" to front of message 
    WriteToOutput("TRACE: {0}", msg); 
    } 
    else 
    if (WasWrittenFromDebug) 
    { 
    //Before writing to output, add "DEBUG" to front of message 
    WriteToOutput("DEBUG: {0}", msg); 
    } 
} 

[EDIT FIN]

Ver this answer he publicado recientemente en respuesta a una pregunta acerca del uso de System.Diagnostics.

Hay mucha información y mucha información en los enlaces dentro de esa respuesta sobre cómo usar System.Diagnostics, con énfasis en el uso de TraceSources en lugar de Trace.WriteLine y Debug.WriteLine.

Desde su pregunta, parece que es posible que desee escribir algo de código como este:

public void MyFunction(int x, int y) 
{ 
    Trace.WriteLine("Entering MyFunction. x = {0}, y = {1}", x, y); 

    int product = x * y; 

    Debug.WriteLine("product = {0}", product); 

    Trace.WriteLine("Exiting MyFunction"); 
} 

y que le parecer como el resultado de seguimiento para ir a uno TraceListener y la salida de depuración para ir a otro TraceListener . O dentro de un TraceListener (tal vez que usted mismo escribiría) le gustaría poder decir si un Write/WriteLine dado es en realidad un Trace.Write o un Debug.Write. No creo que eso sea realmente posible.

¿Desea también controlar la salida Trace y Debug de otras formas (puede activar y desactivar una?

Si usa TraceSources, puede controlar fácilmente el nivel de su seguimiento/registro y, si lo desea, puede enviar la salida de algunos TraceSources a un TraceListener y la salida de otros a un diferente TraceListener (y algunos TraceSources incluso podrían escribir en múltiples TraceListeners).

Por lo tanto, el uso de TraceSources, puede escribir código como este:

public class MyClass 
{ 
    //Static variable, so all instances of MyClass will have access to the same instance 
    //of the TraceSource 
    private static readonly TraceSource ts = new TraceSource("MyClass"); 

    public void MyMethod(int x, int y) 
    { 
    ts.TraceEvent(TraceEventType.Information, 0, "Entering MyMethod. x = {0}, y = {1}", x, y); 

    int product = x * y; 

    ts.TraceEvent(TraceEventType.Debug, 0, "Product = {0}", product); 

    ts.TraceEvent(TraceEventType.Information, 0, "Exiting MyMethod."); 
    } 
} 

¿Cuáles son los beneficios de TraceSource en este ejemplo?

1. En su app.config puede girar el TraceSource "MyClass" encendido o apagado o se establece en un nivel determinado. Si lo configura en "Depurar", se escribirán los mensajes de Depuración e Información. Si lo configura en "Información", solo se registrarán los mensajes de Información. Si configura más alto que "Información", ninguno de los mensajes en el ejemplo se registrará.

2. En su app.config puede enviar la salida de "MyClass" a uno o más TraceListeners. Si tuviera más TraceSources ("YourClass", "HisClass"), cada uno podría ir al mismo TraceListener o cada uno podría ir a su propio TraceListener, o cualquier combinación intermedia.

3. En su app.config Puede configurar switching y/o filtering tales que "MyClass" se designa a ir a, por ejemplo, dos TraceListeners. Un TraceListener podría filtrar de forma tal que solo se registran los mensajes "Debug" y el otro podría filtrarse de manera que solo se registran los mensajes de "Información".

Hay mucho más que puedes hacer con TraceSources. Lea el enlace de arriba y los enlaces dentro de esa publicación. Vea el proyecto Ukadc.Diagnostics al que me refiero en la publicación. Essential.Diagnostics es otro proyecto que proporciona extensiones a System.Diagnostics y muestra algunos buenos ejemplos de uso de System.Diagnostics. Here is a good example from MSDN about using TraceSources, filters, and TraceListeners.

En mi opinión, será mejor que intente utilizar TraceSources en lugar de Trace. * Y Debug. * Para agregar el seguimiento/registro a su código.

¡Buena suerte!