How to differentiate between Trace and Debug calls in a custom trace listener?

Trace.Listeners and Debug.Listeners are sharing the same internal collection thus I cannot add a trace listener to Trace.Listeners and a debug listener to Debug.Listeners to differentiate between them.

How can I achieve this?

Edit:

Why I want to do this is simply because I'm wrting a logging layer to our application and I want开发者_如何学Python to keep track of different logs through out the system where Debug/Trace is two sources of logs (there are a couple of other sources too) I want to keep track of.

---

[EDIT]

I missed the part in the title of the question where you mention that this in the context of a custom trace listener. So, apparently you have written (or want to write) a custom TraceListener that could differentiate between Trace.WriteLine and Debug.WriteLine. I think that everything that I say below still holds true as far as TraceSources being preferable to Trace.WriteLine and Debug.WriteLine. However, my answer doesn't necessarily answer your question, except to say that I don't think that it is possible from within a TraceListener's Write and WriteLine methods to tell if they were ultimately invoked because of a call to Trace.WriteLine vs Debug.WriteLine.

It is not clear what you are trying to accomplish, even if you could tell from within the custom TraceListener the ultimate source of call to Write or WriteLine. Whatever it is that you want to accomplish, I have to believe that it would be easier to do if you based your logging statements in your code on TraceSources to begin with.

Could you add some code to your original question that shows how you might write some application code, adding some calls to Trace.WriteLine and Debug.WriteLine. Also, show some code from your custom TraceListener that shows what action you would like to take if you COULD distinguish between Trace.WriteLine and Debug.WriteLine. Something like:

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

[END EDIT]

See this answer I posted recently in response to a question about using System.Diagnostics.

There is a lot of information there and a lot of information in links within that answer about how to use System.Diagnostics, with an emphasis on using TraceSources rather than Trace.WriteLine and Debug.WriteLine.

From your question, it sounds like you might want to write some code like this:

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

AND you would apparently like the Trace output to go to one TraceListener and the Debug output to go to another TraceListener. OR within a TraceListener (maybe that you would write yourself) you would like to be able to tell if a given Write/WriteLine is actually a Trace.Write or a Debug.Write. I don't think that is really possible.

Would you also like to control the Trace and Debug output in other ways (maybe turn one on and one off?

If you would use TraceSources, you could easily control the level of your tracing/logging and you could, if you would like to do so, send the output of some TraceSources to one TraceListener and the output of others to a different TraceListener (and some TraceSources could even write to multiple TraceListeners).

So, using TraceSources, you might write code like this:

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

What are the benefits of TraceSource in this example?

1. In your app.config you can turn the "MyClass" TraceSource on or off or set it to a certain level. If you set it to "Debug", the Debug and Information messages will be written. If you set it to "Information", only the Information messages will be logged. If you set higher than "Information", none of the messages in the example will be logged.

2. In your app.config you can send the output of "MyClass" to one or more TraceListeners. If you had more TraceSources ("YourClass", "HisClass"), each could go to the same TraceListener or each could go to its own TraceListener, or any combination in between.

3. In your app.config you can set up switching and/or filtering such that "MyClass" is designated to go to, for example, two TraceListeners. One TraceListener could filter such that only "Debug" messages are logged and the other could filter such that only "Information" messages are logged.

There is a lot more that you can do with TraceSources. Read the link above and the links within that post. See the Ukadc.Diagnostics project that I refer to in the post. Essential.Diagnostics is another project that provides extensions to System.Diagnostics as well as showing some pretty good examples of using System.Diagnostics. Here is a good example from MSDN about using TraceSources, filters, and TraceListeners.

In my opinion, you will be better off if you try to use TraceSources rather than Trace.* and Debug.* to add tracing/logging to your code.

Good luck!