Distriggerszione della traccia tramite app.config

Sto cercando di utilizzare System.Diagnostics per eseguire alcune registrazioni di base. Immagino che userò ciò che è nella scatola piuttosto che assumere una dipendenza extra come Log4Net o EntLib.

Sono tutto pronto, il tracciamento funziona meravigliosamente. Snippet di codice:

Trace.TraceInformation("Hello World") 

App.config:

            

e il mio piccolo “Hello World” si mostra benissimo nel mio file Trace.log. Ma ora mi piacerebbe distriggersre la traccia, quindi analizzo MSDN e scopro Come: Configurare gli interruttori di traccia . Aggiungo l’elemento e ora il mio app.config ha il seguente aspetto:

               

Il value="0" dovrebbe distriggersre la traccia, almeno se si segue How to: Crea e inizializza gli indicatori di traccia , che ti dice di aggiungere questa riga di codice:

 Dim dataSwitch As New BooleanSwitch("Data", "DataAccess module") 

Non ha senso per me: devo solo dichiarare un’istanza di BooleanSwicth per poter gestire (disabilitare) la traccia tramite il file .config? Dovrei … usare … l’object da qualche parte?

Ad ogni modo, sono sicuro di aver perso qualcosa di veramente ovvio da qualche parte. Per favore aiuto.

Come posso distriggersre la traccia OFF in app.config?

Sono d’accordo con la raccomandazione di @Alex Humphrey di provare a utilizzare TraceSources. Con TraceSources si ottiene un maggiore controllo su come vengono eseguite le istruzioni di registrazione / traccia. Ad esempio, potresti avere un codice come questo:

 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 chiamata TraceSource.TraceEvent controllerà automaticamente il livello del messaggio (TraceEventType.Information) rispetto al livello configurato dello Switch associato e determinerà se il messaggio debba essere effettivamente scritto o meno.

Utilizzando una TraceSource diversa per ciascun tipo, è ansible controllare la registrazione da tali classi singolarmente. È ansible abilitare la registrazione di MyClass1 o disabilitarla o abilitarla, ma è necessario registrarla solo se il livello del messaggio (TraceEventType) è maggiore di un certo valore (forse solo registrare “Avviso” e più in alto). Allo stesso tempo, è ansible triggersre o distriggersre la registrazione in MyClass2 o impostarla su un livello, completamente indipendente da MyClass1. Tutte queste cose di abilitazione / disabilitazione / livello si verificano nel file app.config.

Usando il file app.config, puoi anche controllare tutte le TraceSources (o gruppi di TraceSources) nello stesso modo. Quindi, puoi configurare in modo che MyClass1 e MyClass2 siano entrambi controllati dallo stesso Switch.

Se non si desidera avere TraceSource con nomi diversi per ogni tipo, è sufficiente creare la stessa TraceSource in ogni class:

 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); } } 

In questo modo, è ansible eseguire tutte le registrazioni all’interno dell’applicazione allo stesso livello (o essere distriggerste o utilizzare lo stesso TraceListener o qualsiasi altra cosa).

È inoltre ansible configurare diverse parti della propria applicazione in modo da essere configurabili in modo indipendente senza dover affrontare il “problema” di definire una TraceSource univoca in ciascun 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 la tua class strumentata in questo modo, potresti rendere la parte “DataAccess” del tuo registro app a un livello mentre la parte “Analisi” della tua app si registra a un livello diverso (ovviamente, o entrambe le parti della tua app potrebbero essere configurate in modo che la registrazione sia disabilitata).

Ecco una parte di un file app.config che configura TraceSources e TraceSwitches:

                            

Come si può vedere, è ansible configurare una singola TraceSource e un singolo Switch e tutte le registrazioni avverranno con un unico livello di controllo (ovvero è ansible distriggersre la registrazione o registrarla a un determinato livello).

In alternativa, è ansible definire più TraceSources (e fare riferimento alle TraceSources corrispondenti nel codice) e più Switch. Gli Switch possono essere condivisi (cioè più TraceSources possono usare lo stesso Switch).

In definitiva, impiegando un po ‘più impegno ora per utilizzare TraceSources e per fare riferimento a TraceSources appropriatamente denominate nel codice (ovvero definire logicamente i nomi di TraceSource in modo da poter ottenere il grado desiderato di controllo sull’accesso nella tua app), otterrai significativi flessibilità a lungo termine.

Ecco alcuni link che potrebbero aiutarti con System.Diagnostics man mano che procedi:

.net Best practice di diagnostica?

Registrazione delle migliori pratiche

Qual è l’approccio migliore per la registrazione?

Il framework .Net TraceSource / TraceListener ha qualcosa di simile ai formattatori di log4net?

Nei link che ho postato, viene spesso discussa la struttura di registrazione “migliore”. Non sto cercando di convincerti a cambiare da System.Diagnostics. I collegamenti tendono anche ad avere buone informazioni sull’utilizzo di System.Diagnostics, è per questo che li ho pubblicati.

Molti dei link che ho pubblicato contengono un link a Ukadc.Diagnostics . Questa è una libreria add-on molto interessante per System.Diagnostics che aggiunge una ricca capacità di formattazione, simile a ciò che si può fare con log4net e NLog. Questa libreria impone una dipendenza solo per la configurazione della tua app, non un codice o una dipendenza di riferimento.

Non distriggersre la traccia globalmente in questo modo.

Devi
1) dichiara un interruttore e imposta il suo valore:

    

2) associare questa opzione a TraceSource che si utilizza:

    

Quindi, qualunque cosa tu scriva tramite TraceSource chiamata “MySource” viene filtrata in base al valore dello switch.

Se si utilizzano metodi statici come Trace.Write , suppongo, non è ansible utilizzare gli switch, perché non esiste TraceSource per applicare il filtro.
Se si desidera distriggersre la traccia con metodi statici, è sufficiente rimuovere tutti gli ascoltatori: .

È l’attributo switchValue del nodo di origine:

          

Controlla lo stato di dataSwitch ogni volta che devi effettuare il login, come da:

http://msdn.microsoft.com/en-us/library/aa984285%28v=VS.71%29.aspx

Tuttavia, questo è abbastanza cattivo, dovendo mettere quegli assegni ovunque. È un motivo per cui non vuoi semplicemente rimuovere TraceListener dalla raccolta di listener in app.config?

A parte questo, vorrei investigare usando la traccia di .NET 2.0+ che include TraceSource . La nuova (er) roba offre un livello molto più alto di configurazione e potresti trovare che sia più adatto.

http://msdn.microsoft.com/en-us/library/ms228993.aspx

In ritardo con una breve nota sull’app.config, nel caso in cui si risparmia un paio di giorni dalla vita di qualcuno là fuori:

Si supponga di avere il progetto di avvio (.exe) contenente la class A che utilizza il progetto B (.dll) che contiene classB.

A sua volta, ClassB utilizza una nuova istanza TraceSource (“classB”). Per configurarlo è necessario modificare app.config o projectA. Ottimizzare l’app.config del progettoB non porterà da nessuna parte.

Si noti inoltre che il posizionamento di

  

La sezione all’interno di app.config sembra causare problemi se posta prima della sezione:

  

o dopo la sezione:

  

Almeno nel mio caso, stavo ricevendo degli errori quando ho tentato di posizionarlo in queste posizioni nell’app.config del mio progetto. Il layout che ha funzionato per me è stato:

 < ?xml version="1.0" encoding="utf-8" ?>   ...config sections here if any...                 ...runtime sections here if any...   ...usersettings sections here if any...