title: Logging framework vs System.Diagnostics Tracing
body: <p>As I'm currently setting up Logging in my (Asp.Net Web Api) application I was reading about best practices according logging. I came along this question about <a href="https://stackoverflow.com/questions/576185/logging-best-practices">logging best practices</a>.</p>
  
  <p>I was going the <code>Ninject</code> -> <code>Logging Extensions</code> -> <code>Nlog / Log4Net</code> way, but this question (or should I say answer) made me think a second time.</p>
  
  <p>At the moment I have tracing enabled, log every here and there and it feels a bit messy to have logs and traces which don't add up together.</p>
  
  <p>I think that when I switch to Diagnostics Tracing and build on top of what the framework already gives me I would end up with a more complete trace. A trace which tells a complete story sounds more useful to me then a separate trace and log which both know about a part of the story. And of course I could always separate things again with listeners and filters.</p>
  
  <p>But at the other hand I always learned:</p>
  
  <blockquote>
    <p>Logging != Tracing</p>
  </blockquote>
  
  <p>So this leaves me with the question, should I drop the logging framework, it's the starting phase of the project, or should I stick with it?</p>
  
  <p>And if I drop the logging framework, should I use a interface in case we ever wanna switch to another logging/tracing framework again, or can I just make a dependency on System.Diagnostics? </p>