Simple .net trace

This is the basic lesson we all might have learned when we started .net. But when we enter into complex applications or gain more knowledge over the time, we might have started writing our own complex logging systems or the Microsoft Logging application block. I am sure that at certain point we again think about the simple ways. That happened to me last week when I had to debug communication between our project and a completely unknown single sign on provider.
The scenario is simple. We had to integrate our Silverlight web app with a sign on provider similar to google.In google systems, if we open gmail or orkut it will go to another url for getting username and password and after authentication, it will return to the requested application ie gmail or orkut url. This is the UI side which user sees.But if we speak technically from the programmer perspective, the authentication mechanism has to provide a token in the form of cookies which should be kept at the client side (browser) and for the subsequent requests the token should go along and the application(gmail or orkut) should verify that for validity.If we are the developers of both the systems, this is not at all a big task.
But in our case the authentication provider is fully unknown except its name. No idea what the auth provider returns and in which header and all.And on top of all these, we have no access to this authentication provider from our development machines and we are not in a position to install the same in dev environment. This means we need to log each and every thing which happens between our application and the authentication provider. Microsoft enterprise library is the logging mechanism in our application.But if we log each and everything using the logging block, our application will become a logging application which cannot serve the actual user requests.What ever we put as config to switch on or off the logging that checking will take some CPU cycles which may degrade the server side performance. Moreover I am not a big fan of Enterprise library in terms of performance.So what should be our solution?

Simple Trace.Write statements which can be avoided at the compile time for the production installer msi files.

How to configure the trace destination file in simple way?

We talk about the method which write the log .Now where will this text go? Below is a simple config which route the trace entries to a file.

   <system.diagnostics>

      <trace autoflush="true"  

             indentsize="1">

        <listeners>

          <add name="Listener1" 

               type="System.Diagnostics.TextWriterTraceListener"

               initializeData="E:\Temp\testtrace.txt" />

          <remove name="Default" />

        </listeners>

     </trace>

   </system.diagnostics>

Challenge – Differentiating our trace entries

Use the category when writing trace.Better use the category as <Namespace>.<TypeName>.<MethodName> and open or import the trace file in excel then filter rows based on category.

How to avoid the trace statements in production

If we give the binaries which have the Trace code it will cause performance issues even though we are not using any listeners. It may be very slight in terms of CPU cycles which takes to check whether the trace listener is available or not.This is negligible in most cases but it may come to effect when this logging code is running a server which is supposed to server thousands of request per second.So we must avoid the Trace.write lines from the binaries at the compile time.Its easy


In VS2010 Goto Project Properties->Compile->Advanced Compiler Settings->Uncheck “Define Trace Constant”

When to use

Use this only when you don’t have any other debugging techniques available (test servers)and your logging mechanism feels complicated. Never miss the opportunity to debug using Visual studio in your own machine

Updates

2021-11-03

Sample source code pushed to GitHub.