write practices logger log errores error best c# .net logging trace

c# - practices - Cómo usar TraceSource en todas las clases



trace c# (1)

Hace poco estuve estudiando documentación en TraceSource . Microsift dice que TraceSource es una nueva forma y debería usarse en lugar de la antigua clase Trace.

// create single TraceSource instance to be used for logging static TraceSource ts = new TraceSource("TraceTest"); // somewhere in the code ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found");

Ahora mi pregunta. Tienes un gran proyecto con varias asambleas donde tienes muchas clases. Digamos que quiere rastrear un poco de funcionalidad específica que se distribuye entre las clases. La idea obvia es que debe crear un TraceSource específico.

1) Para trabajar con Tracesource, primero necesito crear una instancia. ¿Qué está pensando MS en compartir esta instancia en varias clases o ensamblajes? ¿Debo crear una clase ficticia con propiedad singleton estática? ¿Qué estás haciendo en ese caso?

2) ¿Por qué necesito la instancia de TraceSource? Cada propiedad se describe en el archivo de configuración. La antigua lógica basada en la clase Trace no requería ninguna instancia y proporcionaba la manera de trabajar solo con métodos estáticos.


* 1. Simplemente defina TraceSource en cada clase donde quiera usarlo. Puede hacer que el TraceSource sea estático para que se comparta entre todas las instancias de la clase en la que lo define. No es necesario compartir la instancia entre todas las clases (tipos) que necesitan el "mismo" TraceSource. Cada vez que declara una nueva instancia TraceSource (TraceSource ts = new TraceSource ("somename"); obtiene un nuevo objeto TraceSource, pero hace referencia a la misma información de configuración. Por lo tanto, si crea una nueva fuente TraceSource en cada una de varias clases y Si utiliza el mismo nombre para cada uno, obtendrá diferentes instancias de TraceSource, pero todas se configurarán de la misma manera. En resumen, no es necesario intentar compartir las instancias de TraceSource entre las clases. Tampoco es necesario crear instancias de TraceSource. una clase ficticia con un singleton estático. Consulte mis ejemplos a continuación. También he incluido varios enlaces más de aquí en SO que describen cómo trabajar con TraceSources.

// // In this example, tracing in classes A and B is controlled by the "TraceTest" TraceSource // in the app.config file. Tracing in class C is controlled by the "TraceTestTwo" // TraceSource in the app.config. // // In addition to using different TraceSource names, you can also use SourceSwitches // (in the app.config). See some examples of app.config in the // "turning-tracing-off-via-app-config" link below. // public class A { private static readonly TraceSource ts = new TraceSource("TraceTest"); public void DoSomething() { ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found"); } } public class B { // //Use the same config info for TraceTest in this class //It''s ok to use a different instance of TraceSource, but with the same name, //in this class, the new instance will be configured based on the params in the //app.config file. // private static readonly TraceSource ts = new TraceSource("TraceTest"); public void DoSomething() { ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found"); } } public class C { // //Use a different TraceSource in this class. // private static readonly TraceSource ts = new TraceSource("TraceTestTwo"); public void DoSomething() { ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found"); } }

* 2. Un beneficio del uso de múltiples TraceSources es que tiene un control más granular de su rastreo. Puede rastrear a través de "TraceTest" en un nivel (o no hacerlo) y mediante "TraceTestTwo" en un nivel diferente (o, de nuevo, no hacerlo). Puede enviar cada TraceSource a su propio TraceListener o enviarlo todo al mismo TraceListener, o mezclar y combinar. Compare la capacidad de adaptar la configuración de TraceSources individuales a la limitación de usar únicamente los métodos estáticos en la clase Trace. Puede configurar dónde va la información de "rastreo" (qué TraceListener (s)) o el nivel de la información de "rastreo", pero no puede controlar el nivel por clase o área funcional como puede hacerlo cuando usa TraceSources. Finalmente, un beneficio más para múltiples TraceSources es la información de contexto "libre" que puede obtener en su salida. De forma predeterminada (u opcionalmente, no recuerdo), TraceListener registrará el nombre de TraceSource que registró un mensaje. Entonces, puede ver esa línea en su salida y hacerse una idea de la clase o área funcional de donde provino sin tener que poner un registro de información contextual en el sitio de llamadas. En los ejemplos de código anteriores, la salida de rastreo de las clases A y B se etiquetará con "TraceTest" y la salida de rastreo de la clase B se etiquetará con "TraceTestTwo".

Por favor, perdone el bombardeo de enlace a continuación, pero he publicado información bastante buena (¡si me permite decirlo!) Sobre TraceSource y System.Diagnostics en el pasado.

Si va a usar TraceSource, considere usar la biblioteca mencionada en esta publicación SO para formatear su salida como log4net / NLog:

¿El framework .Net TraceSource / TraceListener tiene algo similar a los formateadores de log4net?

Consulte mi respuesta en esta publicación para obtener más información sobre el uso de TraceSource y algunas ideas sobre cómo puede mejorar su "experiencia de TraceSource".

Más información sobre TraceSource: Agregar métodos de seguimiento a System.Diagnostics.TraceListener

Más información sobre TraceSource: System.Diagnostics.Debug namespace vs Other logging solutions (log4net, MS Enterprise Library, etc.)

Más información sobre TraceSource: Desactivar el seguimiento a través de app.config