Отключение трассировки через приложение.конфиг

Я согласен с рекомендацией @Alex Humphrey попробовать использовать TraceSources. С TraceSources вы получаете больше контроля над тем, как выполняются ваши операторы ведения журнала/трассировки. Например, у вас может быть такой код:

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

Источник Трассировки.Вызов TraceEvent автоматически проверяет уровень сообщения (TraceEventType.Информация) против настроенного уровня связанного коммутатора и определит, должно ли сообщение фактически быть записано из.

С помощью другого имени TraceSource для каждого типа можно управлять журналированием из этих классов по отдельности. Вы можете включить ведение журнала MyClass1, или вы можете отключить его, или вы можете включить его, но иметь его журнал только в том случае, если уровень сообщения (TraceEventType) больше определенного значения (возможно, только журнал "предупреждение" и выше). В то же время вы можете включить или выключить вход в MyClass2 или установить уровень, полностью независимо от MyClass1. Все это включение/отключение / уровень вещи происходит в приложении.конфигурационный файл.

С помощью приложения.файл конфигурации, вы также можете управлять всеми TraceSources (или группами TraceSources) таким же образом. Таким образом, вы можете настроить так, чтобы MyClass1 и MyClass2 управлялись одним и тем же коммутатором.

если вы не хотите иметь разные имена TraceSource для каждого типа, вы можете просто создать один и тот же TraceSource в каждом классе:

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

таким образом, вы можете сделать все вход в приложение происходит на том же уровне (или отключается, или идет тот же TraceListener, или что угодно).

вы также можете настроить различные части вашего приложения для независимой настройки без необходимости идти "проблема" определения уникального TraceSource в каждом типе:

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

С вашим классом, инструментированным таким образом, вы можете сделать часть "DataAccess" вашего журнала приложений на одном уровне, а часть "анализ" вашего приложения другой уровень (конечно, любая или обе части вашего приложения могут быть настроены так, что ведение журнала отключено).

вот часть приложения.файл конфигурации, который настраивает TraceSources и 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>

как вы можете видеть, вы можете настроить один TraceSource и один коммутатор, и все ведение журнала будет происходить с одним уровнем управления (т. е. вы можете отключить все выходы из системы или сделать его журнал на определенном уровне).

кроме того, вы можете определить несколько TraceSources (и ссылки на соответствующие TraceSources в коде) и несколько переключателей. Коммутаторы могут быть общими (т. е. несколько TraceSources могут использовать один и тот же коммутатор).

в конечном счете, приложив немного больше усилий, чтобы использовать TraceSources и ссылаться на правильно названные TraceSources в вашем коде (т. е. определить имена TraceSource логически, чтобы вы могли иметь желаемую степень контроля над входом в приложение), вы получите значительную гибкость в конечном счете.

вот несколько ссылок, которые могут помочь вам с системой.Диагностика по мере продвижения вперед:

рекомендации по диагностике .net?

лучшие практики ведения журнала

каков наилучший подход к регистрации?

имеет ли .NET tracesource/tracelistener framework что-то похожее на Форматеры log4net?

в ссылках, которые я написал, Есть часто обсуждается" лучшая " структура ведения журнала. Я не пытаюсь убедить вас отказаться от системы.Диагностика. Ссылки также имеют хорошую информацию об использовании системы.Диагностика, вот почему я их разместил.

несколько ссылок, которые я разместил, содержат ссылку на Ukadc.Диагностика. Это действительно круто добавить на библиотеку для системы.Диагностика, которая добавляет богатые возможности форматирования, подобно тому, что вы можете сделать с log4net и NLog. Эта библиотека устанавливает config-только зависимость от вашего приложения, а не зависимость от кода или ссылки.