Log Parser

After starting to use the new log feature in Framework 2.x, how do you analyze the log file. There is a free tool provided by Microsoft to do just that. That tool can be obtained from here. However, it can be quite challenging since it is a line command utility. Also in order for it to work, you need to make sure you use , as the delimiter so that it can treat your log file as a CSV file.

Luckily somebody else had taken an initiative to make it better by coming up with a GUI interface called Visual LogParser, unfortunately, I found this to be lacking. It did not allow some of the options.

You can read more about the features of LogParser from Microsoft, or from another blogger here who has also linked some other resources.

Enhanced Tracing in Framework 2.0

Following up on the previous post on logging, seems that the same mechanism can be used on the tracing. In the case of application with multiple modules, you can create multiple TraceSource and associate each TraceSource to each module. That way, you can trace output from each module separately.

To activate the tracesource, you just have to retrieve the tracesource in your program as follows:

Dim ts as new TraceSource("MainForm")

"MainForm" is the name of the tracesource as seen in the config file:

  <system.diagnostics>
 <sources>
   <!-- This section defines the logging configuration for My.Application.Log -->
   <source name="MainForm" switchValue="All">
     <listeners>
       <add name="LogToFile"/>
     </listeners>
   </source>
 </sources>
 <switches>
   <add name="DefaultSwitch" value="All" />
   <add name="ActSwitch" value="ActivityTracing" />
   <add name="VerSwitch" value="Verbose" />
 </switches>
 <sharedListeners>
   <!-- add name="FileLog"
        type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
        initializeData="FileLogWriter"/ -->
   <!-- Uncomment the below section and replace APPLICATION_NAME with the name of your application to write to the Application Event Log -->
   <!--<add name="EventLog" type="System.Diagnostics.EventLogTraceListener" initializeData="APPLICATION_NAME"/> -->
   <add name="LogToFile" type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
       initializeData="FileLogWriter"
       logFileCreationSchedule="Daily"
       traceOutputOptions="DateTime"
       BaseFileName="MainWin"
       location="Custom"
       CustomLocation="c:\log\"
       Delimiter ="|"
       AutoFlush="True"
       Append="True"
     />
 </sharedListeners>
</system.diagnostics>

This is superior to the one available in Framework 1.1 because, instead of using a If statement to check the tracelevel prior to performing Trace.WriteLine, you use ts.TraceEvent(TraceEventType.Information, 1, "Started Trace").

In framework 1.1, I facilitated this by creating a subroutine:

        '==================================================
        ' performs a trace write if the switch is > then the pLevel
        ' If flg = 0 then do a trace.write
        ' if flg = 1 then do a trace.writeline
        ' =================================================
        Sub traceMsg(ByRef tSwitch As TraceSwitch, ByVal pLevel As TraceLevel, _
            ByVal pMsg As String, Optional ByVal traceCat As String = "Debug", _
            Optional ByVal flg As Integer = 0)

            If tSwitch.Level >= pLevel Then
                If flg = 0 Then
                    Trace.Write(traceCat, pMsg)
                Else
                    Trace.WriteLine(traceCat, pMsg)
                End If

            End If
        End Sub

Error Handling in Applications

With Java and Microsoft .Net applications, the try ... catch statement is very powerful. There are many articles that says that the process is very costly. However, I found the following to be very effective in simplifying my application (will use vb.net in the example but can come up with similar example in Java if requested):

Sub process1()

try
  ...
  Process2()
  ...
catch (ex as exception)
  throw new Exception("[process01]" & ex.message)
end try

End Sub

Sub Process2
 try
   ...
 catch (ex as Exception)
   throw new Exception("[process02]" & ex.Message())
 End Try
End Sub

...

Public Sub Main(ByVal args() As String)
try
  ...
  process1()
catch (ex As Exception)
  Console.Writeline(ex.Message())
End Try

In the example above, if an error happens in Process2, it will be thrown upwards until it reaches the main subroutine. So when you see the error message, you know that the error was encountered in Process2. You will then see the error as

[process1][Process2]...


I found this makes it easier to zoom into the errors in my application. This concept can be used in Console applications, Web Applications and Windows Application. Just need to make sure that the message is displayed somewhere.