estoy de acuerdo con la recomendación de @Alex Humphrey intentar usar TraceSources. Con TraceSources obtendrá más control sobre cómo se ejecutan sus instrucciones de registro/rastreo. Por ejemplo, usted podría tener un código como éste:
public class MyClass1
{
private static readonly TraceSource ts = new TraceSource("MyClass1");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
public class MyClass2
{
private static readonly TraceSource ts = new TraceSource("MyClass2");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
La llamada TraceSource.TraceEvent comprobará automáticamente el nivel del mensaje (TraceEventType.Information) frente al nivel configurado del interruptor asociado y determinará si es o no el el mensaje debería escribirse.
Al usar un TraceSource de nombre diferente para cada tipo, puede controlar el registro de esas clases individualmente. Puede habilitar el registro de MyClass1 o puede deshabilitarlo o puede habilitarlo, pero haga que se registre solo si el nivel del mensaje (TraceEventType) es mayor que un cierto valor (tal vez solo inicie sesión "Advertencia" y más). Al mismo tiempo, podría activar o desactivar el inicio de sesión en MyClass2 o establecerlo en un nivel, independientemente de MyClass1. Todas estas cosas de habilitación/inhabilitación/nivel ocurren en el archivo app.config.
Utilizando el archivo app.config, también puede controlar todos los TraceSources (o grupos de fuentes Trace) de la misma manera. Entonces, podría configurar para que MyClass1 y MyClass2 sean controlados por el mismo Switch.
Si no quiere tener un TraceSource nombre diferente para cada tipo, usted podría crear el mismo TraceSource en cada clase:
public class MyClass1
{
private static readonly TraceSource ts = new TraceSource("MyApplication");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
public class MyClass2
{
private static readonly TraceSource ts = new TraceSource("MyApplication");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
De esta manera, se puede hacer todo el registro dentro de la aplicación suceda en el mismo nivel (o estar apagado o ir al mismo TraceListener, o lo que sea).
También puede configurar diferentes partes de la aplicación que permite una configuración independiente sin tener que pasar el "problema" de la definición de un TraceSource único en cada tipo:
public class Analysis1
{
private static readonly TraceSource ts = new TraceSource("MyApplication.Analysis");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
public class Analysis2
{
private static readonly TraceSource ts = new TraceSource("MyApplication.Analysis");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
public class DataAccess1
{
private static readonly TraceSource ts = new TraceSource("MyApplication.DataAccess");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
public class DataAccess2
{
private static readonly TraceSource ts = new TraceSource("MyApplication.DataAccess");
public DoSomething(int x)
{
ts.TraceEvent(TraceEventType.Information, "In DoSomething. x = {0}", x);
}
}
Con su clase instrumentado esta manera, se pudo hacer que la parte "DataAccess" del registro de su aplicación esté en un nivel mientras que la parte "Análisis" de su aplicación se conecta a un nivel diferente (por supuesto, una o ambas partes de su aplicación podrían configurarse para que el registro esté deshabilitado).
Aquí es una parte de un archivo app.config que configura TraceSources y TraceSwitches:
<system.diagnostics>
<trace autoflush="true"></trace>
<sources>
<source name="MyClass1" switchName="switch1">
<listeners>
<remove name="Default"></remove>
<add name="console"></add>
</listeners>
</source>
<source name="MyClass2" switchName="switch2">
<listeners>
<remove name="Default"></remove>
<add name="console"></add>
</listeners>
</source>
</sources>
<switches>
<add name="switch1" value="Information"/>
<add name="switch2" value="Warning"/>
</switches>
<sharedListeners>
<add name="console"
type="System.Diagnostics.ConsoleTraceListener">
</add>
<add name="file"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="trace.txt">
</add>
</sharedListeners>
</system.diagnostics>
Como se puede ver, se puede configurar un único TraceSource y un solo interruptor y todos los registros que ocurriría con una sola nivel de control (es decir, puede desactivar todo el inicio de sesión o hacer que se registre en un cierto nivel).
De forma alternativa, podría definir múltiples fuentes de traza (y hacer referencia a las fuentes de traza correspondientes en su código) y varios interruptores. Los Switches pueden ser compartidos (es decir, múltiples TraceSources pueden usar el mismo Switch).
En última instancia, realizando un poco más de esfuerzo ahora para usar TraceSources y para hacer referencia a TraceSources apropiadamente nombrados en su código (es decir, definir los nombres de TraceSource lógicamente para que pueda tener el grado de control deseado sobre el inicio de sesión en su aplicación). obtendrá una flexibilidad significativa a largo plazo.
Éstos son algunos enlaces que pueden ayudar con System.Diagnostics a medida que avanza hacia adelante:
.net Diagnostics best practices?
Logging best practices
What's the best approach to logging?
Does the .Net TraceSource/TraceListener framework have something similar to log4net's Formatters?
En los enlaces que publicado, a menudo se debate sobre la "mejor" tala marco de referencia. No estoy tratando de convencerte de que cambies de System.Diagnostics. Los enlaces también tienden a tener buena información sobre el uso de System.Diagnostics, es por eso que los publiqué.
Varios de los enlaces que publiqué contienen un enlace al Ukadc.Diagnostics. Esta es una biblioteca realmente genial para System.Diagnostics que agrega una gran capacidad de formateo, similar a lo que puede hacer con log4net y NLog. Esta biblioteca impone una dependencia de solo configuración en su aplicación, no un código o dependencia de referencia.
Awesome answer. Gracias. :) –
Funciona como un encanto. Falta un elemento '' en el archivo de ejemplo .config. –
Agregué un para cerrar el nodo. –
wageoghe