Trace debug for every method in code

[kplkumar]

This is what my supervisor is looking for.

We want runtime debugging/trace logging. In other words, we want to log
every method that was executed, perhaps the variables in it as well -
everytime the method is executed. This should be such that it can be
turned on/off in a configuration file.

This way it will help us locate the error exactly where it occured and
when and all variables related to it.

Is there someway of doing this in c# .NET? I am new to .NET and I have
never used application blocks either.

 

[Nicholas Paldino [.NET/C# MVP]]

There are a few ways I can think of to do this. The first would be to
have some sort of utility class/method which you can call at the beginning
of each method/property.

Of course, you can see the overhead in maintaining code like this.

The second would be to create a class that derives from
ContextBoundObject, and then create the appropriate attribute to set up the
interception of method/property calls. However, this forces you to burn
your base class, as well as causes a good amount of overhead in serializing
the call stack. On top of that, every class would also derive from
MarshalByRefObject, which could create problems in remoting situations.

You could also hook into the CLR with a custom host, and then use the
debugging interfaces to perform all of the interception, but this will
impact performance as well.

The choice is up to you, and while I agree that in some situations
debugging and trace logging is helpful, I think that the overhead and design
considerations in any of these solutions is not worth the effort. Feel free
to tell your manager that as well.

Hope this helps.

 

[AlanT]

Not too sure from the question.
What is the exact problem that you supervisor wants to solve?

Is it, show a record of every one of your routines that were executed
up to the point where the error happened, or
Show exactly where the error occurred.

If the first, then check out the stackframe from system.diagnostics
Using this you can create a general function that will write out the
routine name to the trace.

sorry about the VB.Net Code

Public Shared Sub EnterRoutine()
LogMessage(LogMessage.LogSeverity.Verbose, "Entering " &
GetRoutineName())
End Sub

Public Shared Sub LeaveRoutine()
LogMessage(LogMessage.LogSeverity.Verbose, "Leaving " &
GetRoutineName())
End Sub

Private Shared Function GetRoutineName() As String

Const FMT_NAME As String = "{0}::{1}"

Dim st As New StackTrace(True)
' walk back up the stack 2 levels (TraceEnter/Leave() and then
original location)
Dim sf As StackFrame = st.GetFrame(2)

Return String.Format(FMT_NAME, sf.GetMethod.ReflectedType.ToString,
_
sf.GetMethod.Name)

End Function


In general I have found that this is not very useful - you can end up
with a hugh dump with very little useful information


If you want to just know where the problem occured - check the
Stacktrace in the exception object


For turning On/Off with a config file, check out the docs for
TraceListeners.

hth,
Alan.

 

[AlanT]

Not too sure from the question.
What is the exact problem that you supervisor wants to solve?

Is it, show a record of every one of your routines that were executed
up to the point where the error happened, or
Show exactly where the error occurred.

If the first, then check out the stackframe from system.diagnostics
Using this you can create a general function that will write out the
routine name to the trace.

sorry about the VB.Net Code

Public Shared Sub EnterRoutine()
LogMessage(LogMessage.LogSeverity.Verbose, "Entering " &
GetRoutineName())
End Sub

Public Shared Sub LeaveRoutine()
LogMessage(LogMessage.LogSeverity.Verbose, "Leaving " &
GetRoutineName())
End Sub

Private Shared Function GetRoutineName() As String

Const FMT_NAME As String = "{0}::{1}"

Dim st As New StackTrace(True)
' walk back up the stack 2 levels (TraceEnter/Leave() and then
original location)
Dim sf As StackFrame = st.GetFrame(2)

Return String.Format(FMT_NAME, sf.GetMethod.ReflectedType.ToString,
_
sf.GetMethod.Name)

End Function


In general I have found that this is not very useful - you can end up
with a hugh dump with very little useful information


If you want to just know where the problem occured - check the
Stacktrace in the exception object


For turning On/Off with a config file, check out the docs for
TraceListeners.

hth,
Alan.

 

[kplkumar]

Alright, this is what my suervisor wants.

For every method that is entered and exited in the sequence of
execution, I need an entry in a trace.log file. Other information such
as time it entered and exited, other methods called(in a treee
structure), and other misc information would be helpful.

So I looked at Enterprise Library 1.0 and found that I can use
something called Tracer like this.

private void button1_Click(object sender, EventArgs e)
{
using (new Tracer("Trace"))
{
method1();
// more statements
}
}

This should be done in every method, to acheive something like what I
mentioned above. This can be controlled by changed the App.config using
the EL Configuration tool.

(or)

We can do this without using EL simply by,

private void button1_Click(object sender, EventArgs e)
{
System.Diagnostics.Trace.WriteLine("Entering button1_Click");
// do something
System.Diagnostics.Trace.WriteLine("Exiting button1_Click");
}

____________________________________________________________

In my opinion both pose the same problem. The developer has to
explicitly put the trace statements inside every method definition.
Although the EL let's you turn on and off the trace at runtime, there
is no optimization of code while compilation. So I iwll have hundreds
of lines of these "using(Tracer....." statements compiled as part of my
deployment code. But using the "System.Diagnostics.Trace..." this can
be avoided by turning off the TRACE in the "Conditional Compilation
Constants" setting in the project properties, but this does not allow
you to turn on/off during runtime unlike the EL.

So where should I hit the middle ground??? Any suggestions.