While Loupe works with Trace logging out of the box, there are some steps you can take to get the most out of it.

Avoid Write and WriteLine

Less information is available to the logging system when these calls are used.  They are treated as Verbose log messages.  To emulate traditional raw-text output formats, the Loupe Agent will buffer multiple calls to Write until a WriteLine is received into one message (potentially with embedded carriage returns).  Depending on your situation this can be an imperfect rendering, and causes all of the calls to Write to be attributed to the same point in the source code.  By creating a full message you can get the best visual presentation and usability when viewing logs.

Supply the Exception Object

If you pass in the exception object as an argument then it is both included in the message and stored independently as an exception in the log file for enhanced viewing.  If you want to pre-format it, supply the exception as an additional parameter (with no matching insertion point in the format string) and it will still be captured.  Only the first exception argument is stored.

Remove Redundant Information from Messages

Loupe automatically determines the current class & method for each log message, even when submitted through Trace or Debug.  Therefore, you shouldn't include these elements in your log message as it will clutter up the log message display unnecessarily.  Similarly, it isn't necessary to include the full exception details in the text of the message.  

Write Messages in a Summary - Detail format

For longer messages consider using a Summary - Detail format like "Opening Database Connection\r\nOpened new connection to database {0} on server {1}" with a summary being the text up to a carriage return and line feed.  Loupe will automatically treat this as a caption/description format which works well with the analysis capabilities.  For example, one of the default Loupe views groups messages by caption so in the example above all of the database connection open messages would be grouped together regardless of the detail.  This can help end users find important information more quickly than when the log is entirely full of unique messages.

Review your Severities

Development teams often struggle with severity.  Commonly log messages tend to gravitate to the bottom or top of the severity hierarchy.  To have the most effective use of severity, consider:

• Severity from the user's perspective:  Since the log messages are primarily read by support staff the messages should be written such that severities are based on the impact to the user running the application.  Many developers think in terms of the severity to the particular section of code that is executing.  For example, if the routine is supposed to open a database and it can't find it, that's an error.  However, if the system can automatically recover from this and indeed it's an expected event (for example on first time startup the database doesn't exist) then it isn't an error from the perspective of the user. 
• Errors should require review:  If you record something as an error then expect that support staff likely will look at that message each time a log shows up with it.  Consider carefully if the message warrants that or if perhaps it should just be a warning or even an information.  For example, if you can recover from the problem it's probably just an information message because the user didn't experience a problem.
• Most messages are verbose:  Any log message that isn't a call to action and doesn't indicate an abnormal condition is a verbose message.  Unfortunately, Trace doesn't directly support Verbose messages.  Loupe maps all calls to Write and WriteLine to the Verbose status, making Trace.WriteLine largely equivalent to the (missing) Trace.TraceVerbose.  Alternately, just use Trace.TraceInformation (and users will quickly learn to hide all Information and Verbose messages in the viewer)

Consider Converting to the Loupe API

The Loupe Logging API is designed for easy conversion from Trace by providing matching calls on the Log object.  IN most cases you can replace "Trace." with "Log." and recompile.  Why do this?

• Additional Features:  The Loupe API includes additional overloads to allow explicit specification of exception information and caption/description as separate fields among other features.
• Simpler Configuration:  You no longer need to add a trace listener configuration in the App.Config file.

For more information, see Developer's Guide - Logging - Directly to Loupe .