c# - Desactivando el rastreo a través de app.config
.net vb.net (5)
Compruebe el estado de dataSwitch cada vez que necesite iniciar sesión, según:
http://msdn.microsoft.com/en-us/library/aa984285%28v=VS.71%29.aspx
Sin embargo, eso es bastante desagradable, tener que poner esos cheques en todas partes. ¿Es una razón por la que no desea simplemente eliminar TraceListener de la colección de escuchas en app.config?
Aparte de eso, investigaría usando el rastreo de .NET 2.0+ que incluye TraceSource . El nuevo (er) material ofrece un grado mucho más alto de configuración, y usted puede encontrar que es más adecuado.
Estoy tratando de usar System.Diagnostics para hacer un registro muy básico. Me imagino que usaría lo que está en la caja en lugar de asumir una dependencia adicional como Log4Net o EntLib.
Estoy todo preparado, el rastreo está funcionando maravillosamente. Fragmento de código:
Trace.TraceInformation("Hello World")
App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="TraceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="Trace.log" traceOutputOptions="DateTime" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
</configuration>
y mi pequeño "Hello World" se muestra muy bien en mi archivo Trace.log. Pero ahora me gustaría apagar el rastreo, así que entro en MSDN y encuentro Cómo configurar los interruptores de rastreo . Agrego el elemento <switches> , y ahora mi app.config tiene este aspecto:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="TraceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="Trace.log" traceOutputOptions="DateTime" />
<remove name="Default" />
</listeners>
</trace>
<switches>
<add name="Data" value="0" />
</switches>
</system.diagnostics>
</configuration>
El value="0" debe desactivar el rastreo, al menos si sigue Cómo: Crear e inicializar los interruptores de rastreo , que le indica que agregue esta línea de código:
Dim dataSwitch As New BooleanSwitch("Data", "DataAccess module")
Eso no tiene sentido para mí: ¿tengo que declarar una instancia de BooleanSwicth para poder administrar (deshabilitar) el rastreo a través del archivo .config? ¿Debería gustarme ... usar ... el objeto en alguna parte?
De todos modos, estoy seguro de que me perdí algo realmente obvio en alguna parte. Por favor ayuda.
¿Cómo desactivo el rastreo en app.config?
Es el atributo switchValue del nodo fuente:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Off"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "somePath" />
</listeners>
</source>
</sources>
<trace autoflush="true" />
Estoy de acuerdo con la recomendación de @Alex Humphrey de intentar usar TraceSources. Con TraceSources, usted obtiene más control sobre cómo se ejecutan sus instrucciones de registro / seguimiento. Por ejemplo, podrías tener un código como este:
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 verificará automáticamente el nivel del mensaje (TraceEventType.Information) con el nivel configurado del conmutador asociado y determinará si el mensaje debe escribirse o no.
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 hacer que se registre solo si el nivel del mensaje (TraceEventType) es mayor que un cierto valor (tal vez solo se registre "Advertencia" y superior). Al mismo tiempo, puede activar o desactivar el inicio de sesión en MyClass2 o establecer un nivel, completamente independiente de MyClass1. Todas estas cosas de habilitación / deshabilitación / nivel ocurren en el archivo app.config.
Usando el archivo app.config, también puede controlar todos los TraceSources (o grupos de TraceSources) de la misma manera. Por lo tanto, puede configurarlo para que MyClass1 y MyClass2 estén controlados por el mismo Switch.
Si no desea tener un TraceSource de nombre diferente para cada tipo, puede 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, puede hacer que todos los registros dentro de su aplicación se realicen al mismo nivel (o que se desactiven o vayan al mismo TraceListener, o lo que sea).
También puede configurar diferentes partes de su aplicación para que se puedan configurar de forma independiente sin tener que pasar por el "problema" de definir 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 instrumentada de esta manera, podría hacer que "DataAccess" forme parte de su registro de aplicaciones en un nivel, mientras que el "Análisis" sea parte de su aplicación en un nivel diferente (por supuesto, cualquiera o ambas partes de su aplicación podrían configurarse así que el registro está deshabilitado).
Aquí hay 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 puede ver, puede configurar un único TraceSource y un solo Switch y todo el registro se produciría con un solo nivel de control (es decir, podría desactivar todo el registro o hacer que se registre a un cierto nivel).
Alternativamente, puede definir múltiples TraceSources (y hacer referencia a las TraceSources correspondientes en su código) y múltiples Switches. Los Switches pueden ser compartidos (es decir, múltiples TraceSources pueden usar el mismo Switch).
En última instancia, al poner un poco más de esfuerzo para usar TraceSources y hacer referencia a TraceSources nombrados apropiadamente en su código (es decir, definir los nombres de TraceSource de manera lógica para que pueda tener el grado deseado de control sobre el registro en su aplicación), obtendrá una ventaja significativa. Flexibilidad a largo plazo.
Aquí hay algunos enlaces que pueden ayudarlo con los diagnósticos del sistema. A medida que avanza:
¿Las mejores prácticas de diagnóstico de red?
¿Cuál es el mejor enfoque para el registro?
¿Tiene el marco .Net TraceSource / TraceListener algo similar a los formateadores de log4net?
En los enlaces que publiqué, a menudo se analiza el "mejor" marco de registro. No estoy tratando de convencerte de cambiar 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 he publicado contienen un enlace a Ukadc.Diagnostics . Este es un complemento realmente genial en la biblioteca para System.Diagnostics que agrega una gran capacidad de formato, 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 una dependencia de referencia.
No desactivas el rastreo global de esta manera.
Tienes que
1) declarar un interruptor y establecer su valor:
<switches>
<add name="MySwitch" value="Information"/>
</switches>
2) asocie este interruptor con un TraceSource que utiliza:
<sources>
<source name="MySource" switchName="MySwitch"/>
</source>
Por lo tanto, todo lo que escriba a través de TraceSource llamado "MySource" se filtra de acuerdo con el valor del interruptor.
Si usa métodos estáticos como Trace.Write , supongo, no puede usar conmutadores en absoluto, porque no hay un TraceSource para aplicar el filtro.
Si desea desactivar el rastreo por métodos estáticos, simplemente elimine todos los escuchas: <listeners> <clear/> </listeners> .
Se unió tarde con una breve nota al pie sobre la aplicación .config, en caso de que esto salve un par de días de la vida de alguien:
Supongamos que tiene el proyecto de inicio (.exe) que contiene classA que utiliza projectB (.dll) que contiene classB.
ClassB a su vez hace uso de una nueva instancia de TraceSource ("classB"). Para configurarlo necesitas modificar el app.config o el projectA. Ajustar la aplicación .config de projectB no llevará a ninguna parte.
También tenga en cuenta que la colocación de la
<system.diagnostics>
La sección dentro de app.config parece estar causando problemas si se coloca antes de la sección:
<configSections>
o después de la sección:
<userSettings>
Al menos en mi caso, recibía errores cuando intentaba colocarlo en estas ubicaciones en la aplicación .config de mi proyecto. El diseño que funcionó para mí fue:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
...config sections here if any...
</configSections>
<system.diagnostics>
<trace autoflush="true"/>
<sources>
<source name="classB"
switchName="mySwitch"
switchType="System.Diagnostics.SourceSwitch" >
<listeners>
<clear/>
<add name="textwriterListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="ClassBLog.txt"
traceOutputOptions="DateTime" />
</listeners>
</source>
</sources>
<switches>
<add name="mySwitch" value="Verbose" />
</switches>
</system.diagnostics>
<runtime>
...runtime sections here if any...
</runtime>
<userSettings>
...usersettings sections here if any...
</userSettings>
</configuration>