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.

My First Look at EnterpriseLibrary.Logging

Last week I got opportunity to work with the logging module of our application.It was done by one of my colleague and he told that it is done using Logging module of .Net EnterpriseLibrary.
After looking around the code, I was surprised on the lines of code below which does the logging.Rest is all taken care by configuration entries in web.config.

using (new Tracer("My Tracer"))
{
    LogEntry le = new LogEntry() { Message = message };
    Logger.Write(le);
}

When I looked into the web.config I was able to see some entries in a section named loggingConfiguration

<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

The above code should be inside configSectionsTag.The rest is a new section as follows added after the config sections.

<loggingConfiguration name="Logging Application Block" tracingEnabled="false"
  defaultCategory="" logWarningsWhenNoCategoriesMatch="true">
    <listeners>
       <add fileName="log.log"
           header="-------------Log Message---------------------"
           rollFileExistsBehavior="Increment"
           rollInterval="None"
           rollSizeKB="1024"
           listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.RollingFlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
           traceOutputOptions="None"
           filter="All"
           type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.RollingFlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
           name="FlatFileListener" />
    </listeners>
    <specialSources>
      <allEvents switchValue="All" name="All Events" />
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
        <listeners>
          <add name="FlatFileListener" />
        </listeners>
      </errors>
    </specialSources>
  </loggingConfiguration>

I hope the config is self explanatory.It uses a flat file writer which writes into the file log.log present in the root directory.

I usually afraid of these config entries which cannot be memorized by a developer.If you are also afraid of the config entries use the Enterprise Library Configuration Tool.


This is just a sample.There lot more things which we can do with the logging application block such as format the text which is writing into the file.More properties such as priority,category etc…,Variety of logging  locations such as database,email etc…If I get some more extra time I will surely blog about the same.More details can be found in the below links.

http://bloggingabout.net/blogs/dennis/archive/2009/07/21/quickstart-tutorial-into-enterprise-library-logging.aspx


http://www.codeguru.com/csharp/.net/net_framework/systemnamespace/article.php/c11281/


http://www.codeproject.com/KB/architecture/GetLoggingWithEntLib.aspx

NB : Don’t forget to download the CAB and add reference to the following dlls when  you start a new project.

• Microsoft.Practices.EnterpriseLibrary.Common.dll



• Microsoft.Practices.EnterpriseLibrary.Logging.dll



• Microsoft.Practices.ObjectBuilder2.dll

I have uploaded a sample here.