Project Description
In every .NET project, regardless of the technology used, some basic functionality is needed right from the start:
Tracing and how to handle exceptions.
Of course, Visual Studio provides some tracing functionality, but:
- Visual Studio tracing is much too slow and blocking, making it useless for multithreaded applications
- trace processing is run on the calling thread, tracing exceptions give problems to caller
- .NET's tracing classes are overly complicated and difficult to understand
Requirements for Tracing and Error Handling
+ available from the very first line of code (no initial setup necessary)
+ take very little time (few microseconds)
+ trace processing executed on its own thread
+ tracing running continuously, without causing any storage problems
+ trace message filtering and processing accordingly
+ easy extendable (storing trace in db, send email for certain problems, show some messages in GUI, etc.)
![Design Overview]( "Design Overview")
ACoreLib.Tracer writes trace message in an extremely fast buffer. Another thread empties the buffer, processes the trace and finally stores the message in a ring buffer, where the oldest trace messages gets overwritten. For debugging and exception investigations it is usually enough to have just the latest trace messages.
It's configurable to write some trace messages for permanent storage to files and/or to use any custom implemented trace processing.
For a detailed description of ACoreLib.Tracer see Documentation and http://www.codeproject.com/Articles/1142178/ACoreLib-Tracer-Tracing-done-right
Typical use cases
+ Application writes from the very first line of code into the trace what is happening, like which files it tries to open or other resources it tries to access. If the application fails to start, the trace information shows what could be completed successfully and which functionality made the start to fail. This information is very useful if the application runs on a remote machine, where it is difficult to observe, what is going on.
+ When an exception occurs, the trace information gets included in the Exception message, showing what happened just before (!) the exception occurred.
+ Exception and warning messages get stored in a log file. If the file reaches a certain size, a new log file gets created. If there are too many log files, the oldest gets deleted.
+ Exceptions could get emailed to the developers, including the trace.
Other functionality in ACoreLib
+ ExceptionExtension.ToDetailString_: Converting Exception to string with all the exception information, StackTrace, etc.
+ RealTimeTracer: An extremly fast tracer for debugging multithreading problems, even faster than Tracer
+ FifoBuffer: Extremly fast, non blocking, dual threading safe First In First Out buffer.
+ LogFileWriter: Writing strings to size controlled files, deleting old files if there are too many.
+ Tests for important classes
In every .NET project, regardless of the technology used, some basic functionality is needed right from the start:
Tracing and how to handle exceptions.
Of course, Visual Studio provides some tracing functionality, but:
- Visual Studio tracing is much too slow and blocking, making it useless for multithreaded applications
- trace processing is run on the calling thread, tracing exceptions give problems to caller
- .NET's tracing classes are overly complicated and difficult to understand
Requirements for Tracing and Error Handling
+ available from the very first line of code (no initial setup necessary)
+ take very little time (few microseconds)
+ trace processing executed on its own thread
+ tracing running continuously, without causing any storage problems
+ trace message filtering and processing accordingly
+ easy extendable (storing trace in db, send email for certain problems, show some messages in GUI, etc.)
ACoreLib.Tracer writes trace message in an extremely fast buffer. Another thread empties the buffer, processes the trace and finally stores the message in a ring buffer, where the oldest trace messages gets overwritten. For debugging and exception investigations it is usually enough to have just the latest trace messages.
It's configurable to write some trace messages for permanent storage to files and/or to use any custom implemented trace processing.
For a detailed description of ACoreLib.Tracer see Documentation and http://www.codeproject.com/Articles/1142178/ACoreLib-Tracer-Tracing-done-right
Typical use cases
+ Application writes from the very first line of code into the trace what is happening, like which files it tries to open or other resources it tries to access. If the application fails to start, the trace information shows what could be completed successfully and which functionality made the start to fail. This information is very useful if the application runs on a remote machine, where it is difficult to observe, what is going on.
+ When an exception occurs, the trace information gets included in the Exception message, showing what happened just before (!) the exception occurred.
+ Exception and warning messages get stored in a log file. If the file reaches a certain size, a new log file gets created. If there are too many log files, the oldest gets deleted.
+ Exceptions could get emailed to the developers, including the trace.
Other functionality in ACoreLib
+ ExceptionExtension.ToDetailString_: Converting Exception to string with all the exception information, StackTrace, etc.
+ RealTimeTracer: An extremly fast tracer for debugging multithreading problems, even faster than Tracer
+ FifoBuffer: Extremly fast, non blocking, dual threading safe First In First Out buffer.
+ LogFileWriter: Writing strings to size controlled files, deleting old files if there are too many.
+ Tests for important classes
