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

Question

Недавно я изучал документацию по 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 думает о совместном использовании этого экземпляра между различными классами или сборками? Должен ли я создать один фиктивный класс со статическим свойством singleton? Что ты делаешь в этом случае.

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

Answer 1

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

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

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

Есть ли в.Net TraceSource/TraceListener framework что-то похожее на форматеры log4net?

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

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

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

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