Как использовать TraceSource для разных классов

Недавно я изучал документацию на TraceSource. Microsift говорит, что TraceSource является новым способом и должен использоваться вместо старого класса 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");

Теперь мой вопрос. У вас большой проект с несколькими сборками, где у вас много классов. Скажем, вы хотите отслеживать определенный бит функциональности, который распространяется по классам. Очевидная идея заключается в том, что вам нужно создать один конкретный TraceSource.

1) Для работы с Tracesource мне нужно сначала создать экземпляр. Что думает MS о совместном использовании этого экземпляра в разных классах или сборках? Должен ли я создать один фиктивный класс со статическим одноэлементным свойством? Что вы делаете в этом случае.

2) Зачем нужен экземпляр TraceSource? Каждое свойство описано в файле конфигурации. Старая логика, основанная на классе Trace, не требовала какого-либо экземпляра и предоставляла возможность работать только со статическими методами.

Ответ 1

* 1. Просто определите TraceSource в каждом классе, где вы хотите его использовать. Вы можете сделать статический трассировку TraceSource так, чтобы она была распределена между всеми экземплярами класса, в котором вы его определяете. Не нужно делиться экземпляром среди всех классов (типов), которым нужен "тот же" TraceSource. Каждый раз, когда вы уменьшаете новый TraceSource (TraceSource ts = новый экземпляр TraceSource ( "somename" )), вы получаете новый объект TraceSource, но он ссылается на одну и ту же конфигурационную информацию. Таким образом, если вы создаете новый TraceSource в каждом из нескольких классов и вы используете одно и то же имя для каждого из них, вы получите разные экземпляры TraceSource, но все они будут настроены одинаково. Короче говоря, нет необходимости пытаться совместно использовать экземпляры TraceSource среди классов. Также нет необходимости создавать фиктивный класс со статическим синглтоном. См. мои примеры ниже. Я также включил еще несколько ссылок на SO, которые описывают, как работать с 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 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. Одним из преимуществ использования нескольких TraceSources является то, что у вас есть более подробный контроль над трассировкой. Вы можете проследить через "TraceTest" на одном уровне (или вообще нет) и через "TraceTestTwo" на другом уровне (или, опять же, не на всех). Вы можете отправлять каждый TraceSource на свой собственный TraceListener или отправлять все в один и тот же TraceListener, или смешивать и сопоставлять. Сравните способность адаптировать конфигурацию отдельных TraceSources к ограничению использования только статических методов в классе Trace. Вы можете настроить, куда идет информация "трассировка" (какой TraceListener (ы)) или уровень "трассировки", но вы не можете контролировать уровень для каждого класса или функциональной области, как вы можете, используя TraceSources. Наконец, еще одно преимущество для нескольких TraceSources - это "свободная" контекстная информация, которую вы можете получить в своем выпуске. По умолчанию (или необязательно, я не могу вспомнить), TraceListener будет записывать имя TraceSource, который зарегистрировал сообщение. Таким образом, вы можете посмотреть на эту строку в своем выпуске и получить представление о классе или функциональной области, в которой она появилась, без необходимости размещать журнал контекстной информации на сайте вызова. В приведенных выше примерах кода вывод трассировки из классов A и B будет помечен как "TraceTest", а вывод трассировки из класса B будет помечен "TraceTestTwo".

Пожалуйста, простите ссылку на бомбардировку ниже, но я опубликовал некоторую довольно хорошую информацию (если я так говорю сам!) о TraceSource и System.Diagnostics в прошлом.

Если вы собираетесь использовать TraceSource, подумайте об использовании библиотеки, упомянутой в этой публикации для форматирования вашего вывода, например log4net/NLog:

Имеет ли структура .Net TraceSource/TraceListener нечто похожее на Formatters log4net?

См. мой ответ в этом сообщении для получения дополнительной информации об использовании TraceSource и некоторых идей о том, как вы можете улучшить свой "опыт TraceSource".

Дополнительная информация о TraceSource: Добавить методы трассировки в System.Diagnostics.TraceListener

Дополнительная информация о TraceSource: System.Diagnostics.Debug namespace vs Другие решения для ведения журналов (log4net, MS Enterprise Library и т.д.)

Дополнительная информация о TraceSource: Отключение трассировки через app.config