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

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

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

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

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

Does the .Net TraceSource/TraceListener framework have something similar to log4net's Formatters?

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

Более подробную информацию о TraceSource: Add Trace methods to System.Diagnostics.TraceListener

Более подробную информацию о TraceSource: System.Diagnostics.Debug namespace vs Other logging solutions (log4net, MS Enterprise Library, etc.)

Более подробную информацию о TraceSource: Turning tracing off via app.config