Crypto Logger For .Net is a flexible and high-performance logging framework for your .Net software. Crypto Logger comes with a powerful yet easy-to-use logging console to view, search, analyze and manage log data and perform remote-logging and live-logging. It enables you to glean useful information from logged data to facilitate bug-fixing, pinpointing customer reported issues, monitoring, tracing and analyzing the execution of your software in real-time, and much more! Crypto Logger is the ideal logging framework during development, on production systems or on remote customer sites.

1. Logging Best Practices Using Crypto Logger
Logging can be an invaluable tool during all stages of software development right from development to
deployment/production. Good use of logging enables you to record and report errors, maintain audit trials, gather
app usage statistics and gather performance benchmarks. The following are best practices to be used when using
logging in your software:
Know Who Will Consume And Analyze The Logs
Logging output should make sense to the people who will view/Analyze the logs. For example, logging information
targeted at developers will typically be quite different from that targeted at end-users which in turn will be different
from that targeted at system-administrators. For example, end users are likely to have no use for your logs if you
output messages like "Heap error in function ABC" or "Lock cannot be acquired for polling". Generating the correct
type of logging info is important so that the log information can actually be used and understood by the consumers
of the logs.
Decide Beforehand What Type Of Messages Should Be Used For Each Log Level
Loggers typically provide multiple log levels using which messages can be logged. Each level indicates a different
level of severity and/or detail. Typical levels defined are Debug, Info, Warning, Error and Fatal. It is important that
all the members of your team agree beforehand on the type of messages to be used with each log level. This is
necessary so that a log generated during a routine run of the software does not get flooded with Debug log
messages. Similarly, important information which should have the Warning, Error or Fatal levels should not be
logged using the Debug or Info levels. Since there are no hard and fast rules for what constitutes the informational
detail and/or severity associated with each level, it is upto your team to decide this beforehand.
Crypto Logger provides the following levels and guidelines/conventions for when each level should be used:
Level Description
Used during debugging and development of your software. Specifies the maximum level of detail - a
Debug
Logger set at Debug level allows all log entries to be written.
Used when detailed logging info is needed from your software. A Logger set to this level allows only log
Detailed
entries with their levels set to Detailed or higher.
Used during normal operation of your software. A Logger set to this level allows only log entries with
Normal
their level set to Normal or higher.
Used to limit generated logging information to only warnings or more serious conditions during the
Warning operation of your software. A Logger set to this level allows only log entries with their level set to
Warning or higher.
Used to limit generated logging information to only errors or fatal conditions during the operation of
Error
your software. A Logger set to this level allows only log entries with their level set to Error or Fatal.
Used to limit generated logging information to only fatal conditions during the operation of your
Fatal
software. A Logger set to this level allows only log entries with their level set to Fatal.
Log Only As Much As Needed
Logging code is not free - it increases the size of your code and your compiled binaries. Further, the logging code
itself consumes processor time to run. Logging code also requires maintenance just like any other code. Keep these
factors in mind when deciding how much and what type of data to log. You should not log the code execution
progress after each line of code, nor should you produce useless logs contain very little info like "Failure!". Use
your judgment when deciding the quantity and quality of data to log that will provide useful information when it
actually comes time to view and Analyze the logs to resolve issues or gather statistics.

2. Use External Configuration Files
Logging should be configured via an external configuration file so that the log outputs, level, verbosity, etc can be
easily configured without having to recompile your software.
Crypto Logger supports simple XML configuration files. It can also watch external configuration files for changes - if
the file changes, Crypto Logger will automatically reconfigure itself using the changed file.
Ship Production Apps With Logging Configured To Produce Less Log Information
Typically, you should ship production apps that are configured (via external configuration files) to only output Info,
Warning, Error Or Fatal log messages. Only if the software encounters a problem should it be configured (again, via
a configuration file) to output Debug level log messages which can help in trouble-shooting the problem.
Use Buffered Mode To Avoid Repeated Costly Writes To Disk, Network, etc
If you output log messages to targets like disks, or tcp, which are costly in terms of write times, considered using
the buffered mode of your logging software. When a certain quantity of log data is Buffered, all Buffered log data is
written at once which typically saves a considerable amount of time.
Crypto Logger has full support for buffered mode and various triggers which induce flushing.
Use Asynchronous Mode For Performance Critical Code
When logging from performance-critical code, consider using the Asynchronous mode of your logging software. In
Asynchronous mode, log data is Buffered and is written on a background thread so that your performance-critical
code does not wait for the log data to be written.
Crypto Logger has full support for asynchronous mode.
Prepare Data To Be Logged Only If Logging Is Enabled At The Desired Level
Before formatting or otherwise preparing the data to be logged, check that logging is enabled at the desired level
so that time is not wasted in the formatting/preparation of the data.
For example, instead of doing this:
log.MainSession.LogMessage(string.Format("Current time is {0}",DateTime.Now));
use following code:
if(log.MainSession.IsEnabled(LogEntryLevel.Debug))
log.MainSession.LogMessage(string.Format("Current time is {0}",DateTime.Now));

3. Crypto Logger comes with log method overloads which take all format parameters so that you do not have to check
for level and your code remains clean and minimal.
Keep Logging Code Error Free
You should take care that the logging code itself does not cause undesirable effects. The logging code should
remain as transparent as possible to the actual execution of the software and should not cause exceptions, errors,
deadlocks, slowness or other undesirable effects.
This is the overriding principle that is used in the design of Crypto Logger - logging should not alter the behavior or
flow of your software. Any exceptions or errors that occur during logging are handled gracefully and the execution
of the host software continues uninterrupted.
Keep Logging Code In Sync With The Software Code
Many times, the code surrounding the logging code changes, but the log messages are not changed or removed or
added to reflect the changed code. Such out-of-sync logging code may not be very useful in providing helpful
information when the log is viewed or analyzed. So, just like comments, it is important that the log messages and
logging code is updated when the software code changes.