Tracing - How to customize the eXpressAppFramework.log file generation and other aspects of the default tracer behavior

In this short post I wanted to highlight a functionality and APIs I think any application framework must provide out-of-the-box as it is vital for effective debugging and troubleshooting during development and further application maintenance - logging errors and other diagnostic information.

Even though for the majority of our framework users it is sufficient to deal with this logging system using the high-level interface without digging much into its implementation details (e.g., by looking into the auto-generated eXpressAppFramework.log file or checking emails with error details whose sending can be automated with our framework by application administrators), sometimes it is helpful to see what is "under the hood" to consider new capabilities or improvements for your business. 

That said, let me quote my recent update to the old https://www.devexpress.com/kb=Q304721 article (yes, we constandly update our support knowledge base and especially popular public threads with the latest info and solutions) and, hopefully, you will find this information helpful for the future:

Our tracing mechanism relies on the standard .NET Framework logging APIs from the System.Diagnostics and related namespaces. By default, we use the TextWriterTraceListener class that writes all application events into the eXpressAppFramework.log file by means of our helperDevExpress.Persistent.Base.Tracing class. The latter is technically a wrapper above the standard trace listeners . You can learn more on this from eXpressApp Framework > Concepts > Debugging and Error Handling > Log Files.

That said,  there are two general directions on how to implement logging customizations like splitting a single log into separate files or writing the trace output into the database (I am afraid we do not currently provide ready examples or guidelines for these general programming tasks):
1. Implement a fully custom TraceListener class descendant (or use any ready listener like CircularTraceListener, RollingXmlWriterTraceListener or more complex third-party solutions like log4net) and plug-it into your .NET app as described in the corresponding MSDN documentation. This approach is more preferred and can be easier to implement.
     OR
2. Implement a fully custom Tracing class descendant and override its LogError, LogWarning, LogText, LogVerboseText, LogSetOfStrings, LogValue and other methods as you require. Refer to the eXpressApp Framework > Concepts > Debugging and Error Handling > Add Custom Log Entries  article for more details.

For certain tasks, it may also be sufficient to handle the NeedContextInformation and CustomFormatDateTimeStamp events without inheritance.

For more details and troubleshooting tips, be sure to visit our online documentation at Concepts > Debugging and Error Handling, which is constantly updated with the new information. I am also attentive to this aspect of application development, because we have recently made our logging system even more flexible by making it easier to substitute the default Tracing class and its behavior based on the customer requests in this Support Center thread. See the Debugging and Error Handling > Add Custom Log Entries article to see exactly what was done and how these new extensibility points can be used in the current XAF version. 

Here I want to specially thank our loyal and active user community who help us make our products better by providing true and helpful feedback based on the every day real life use - please, keep it going, because we are always considering how to improve your experience.