Как провести различие между вызовами Trace и Debug в специальном прослушивателе трассировки? - PullRequest
5 голосов
/ 14 января 2011

Trace.Listeners и Debug.Listeners совместно используют одну и ту же внутреннюю коллекцию, поэтому я не могу добавить прослушиватель трассировки в Trace.Listeners и прослушиватель отладки в Debug.Listeners, чтобы различать их.

Как мне достичьthis?

Редактировать:

Почему я хочу это сделать, просто потому, что я записываю слой журналирования в наше приложение и хочу отслеживать различные журналы через систему, в которой выполняется отладка/ Trace - это два источника журналов (есть также несколько других источников), которые я хочу отслеживать.

1 Ответ

4 голосов
/ 14 января 2011

[РЕДАКТИРОВАТЬ]

Я пропустил часть в названии вопроса, где вы упоминаете, что это в контексте специального прослушивателя трассировки. Итак, по-видимому, вы написали (или хотите написать) собственный TraceListener, который может различать Trace.WriteLine и Debug.WriteLine. Я думаю, что все, что я скажу ниже, все еще остается верным, поскольку TraceSources предпочтительнее Trace.WriteLine и Debug.WriteLine. Однако мой ответ не обязательно отвечает на ваш вопрос, за исключением того, что я не думаю, что из методов TraceListener Write и WriteLine можно определить, были ли они в конечном счете вызваны из-за вызова Trace.WriteLine vs Debug. .WriteLine.

Непонятно, чего вы пытаетесь достичь, даже если вы можете сказать из пользовательского TraceListener окончательный источник вызова Write или WriteLine. Независимо от того, чего вы хотите достичь, я должен верить, что было бы легче сделать это, если бы вы основывали свои операторы регистрации в своем коде на TraceSources для начала.

Не могли бы вы добавить код к исходному вопросу, который показывает, как можно написать код приложения, добавив несколько вызовов Trace.WriteLine и Debug.WriteLine. Кроме того, покажите некоторый код из вашего пользовательского TraceListener, который показывает, какое действие вы хотели бы предпринять, если вы МОЖЕТЕ различать Trace.WriteLine и Debug.WriteLine. Что-то вроде:

public void WriteLine(string msg)
{
  if (WasWrittenFromTrace)
  {
    //Before writing to output, add "TRACE" to front of message
    WriteToOutput("TRACE: {0}", msg);
  }
  else
  if (WasWrittenFromDebug)
  {
    //Before writing to output, add "DEBUG" to front of message
    WriteToOutput("DEBUG: {0}", msg);
  }
}

[КОНЕЦ РЕДАКТИРОВАНИЯ]

См. этот ответ Я недавно писал в ответ на вопрос об использовании System.Diagnostics.

Там много информации и много ссылок в этом ответе о том, как использовать System.Diagnostics, с акцентом на использование TraceSources, а не Trace.WriteLine и Debug.WriteLine.

Исходя из вашего вопроса, может показаться, что вы захотите написать такой код:

public void MyFunction(int x, int y)
{
  Trace.WriteLine("Entering MyFunction.  x = {0}, y = {1}", x, y);

  int product = x * y;

  Debug.WriteLine("product = {0}", product);

  Trace.WriteLine("Exiting MyFunction");
}

И вы, очевидно, хотели бы, чтобы выходные данные Trace передавались одному TraceListener, а выходные данные отладки - другому TraceListener. ИЛИ внутри TraceListener (может быть, вы бы написали сами), вы хотели бы иметь возможность определить, является ли данная запись / запись на самом деле Trace.Write или Debug.Write. Я не думаю, что это действительно возможно.

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

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

Итак, используя TraceSources, вы можете написать код, подобный следующему:

public class MyClass
{
  //Static variable, so all instances of MyClass will have access to the same instance
  //of the TraceSource
  private static readonly TraceSource ts = new TraceSource("MyClass");

  public void MyMethod(int x, int y)
  {
    ts.TraceEvent(TraceEventType.Information, 0, "Entering MyMethod.  x = {0}, y = {1}", x, y);

    int product = x * y;

    ts.TraceEvent(TraceEventType.Debug, 0, "Product = {0}", product);

    ts.TraceEvent(TraceEventType.Information, 0, "Exiting MyMethod.");
  }
}

Каковы преимущества TraceSource в этом примере?

  1. В вашем app.config вы можете включить или выключить TraceSource MyClass или установить для него определенный уровень. Если вы установите «Отладка», сообщения Отладка и Информация будут записаны. Если вы установите «Информация», будут регистрироваться только информационные сообщения. Если вы установите значение выше «Информация», ни одно из сообщений в примере не будет зарегистрировано.

  2. В вашем app.config вы можете отправить вывод «MyClass» одному или нескольким TraceListener. Если у вас было больше TraceSources («YourClass», «HisClass»), каждый мог перейти на один и тот же TraceListener, или каждый мог перейти на свой собственный TraceListener, или любую другую комбинацию.

  3. В вашем app.config вы можете настроить переключение и / или фильтрацию таким образом, чтобы «MyClass» предназначался для перехода, например, к двум TraceListener. Один TraceListener может фильтровать так, чтобы регистрировались только сообщения «Отладка», а другой мог фильтровать так, чтобы регистрировались только сообщения «Информация».

С TraceSources можно сделать гораздо больше.Прочитайте ссылку выше и ссылки в этом посте.См. Проект Ukadc.Diagnostics , на который я ссылаюсь в посте. Essential.Diagnostics - это еще один проект, который предоставляет расширения для System.Diagnostics, а также показывает довольно неплохие примеры использования System.Diagnostics. Вот хороший пример из MSDN об использовании TraceSources, фильтров и TraceListeners .

По моему мнению, вам будет лучше, если вы попытаетесь использовать TraceSources, а не Trace. * И Debug. * чтобы добавить трассировку / запись в ваш код.

Удачи!

...