Tracing - How to exclude loaded assemblies from the eXpressAppFramework.log file

Just a small tip for XAF developers who have never needed or liked this large "Loaded assemblies" section written into the eXpressAppFramework.log file at startup or every time an exception is thrown:

https://www.devexpress.com/kb=T500609

How to replace XAF exception handling with Logify

I would like to promote a KB article on the subject, which I published yesterday right after receiving a customer request in response to the recent DevExpress Logify: a New Exception Reporting Tool  blog post.

The XAF article describes three typical ways to integrate Logify into an XAF app. Here I want to note that while the third option with a custom trace listener may look a bit complicated now, it is possible that the Logify team will come up with a built-in trace listener in the future (at least I talked about this with the responsible team and they also said that they thought about such an option). This way you will be able to plug-in this listener in an XAF app using a few lines in the configuration file or in code as per How to: Create and Initialize Trace Listeners (MSDN).

We would greatly appreciate it if you inform us of which XAF integration approach (# 1,2,3 or any other) you eventually implemented in your project and how it all worked for you. Thanks in advance!

Object reference not set to an instance of an object. Part 2.

Before you get totally overwhelmed with the upcoming major v16.2 release (learn quick about XAF bits there), I want to further discuss troubleshooting errors while debugging your app, which is something any developer has to do regularly regardless of the used development tools.

Problem

If you have followed my blog for a long time, you may recall my first post devoted to this problem.

In short, it talks about debugging and analyzing exceptions in Visual Studio or looking into the built-in XAF log file for them. More information on the subject is also available in the online documentation at Concepts > Debugging and Error Handling. 

Unfortunately, we still receive quite a lot support calls with just this meaningless screenshots like " Object reference not set to an instance of an object" or similar without any callstacks, inner exceptions, loaded assemblies or any other meaningful diagnostic information that would allow us to help users in the most effective manner. Since such a screenshot does not provide any opportunity to the author or us to learn about the underlying cause of the error, an unnecessary clarification turn around and an accompanying delay always occurs in this case... This is certainly bad for both sides and thus is something we seek to avoid.

Possible solution

With v16.2, XAF WinForms apps will display a better error dialog while you are debugging your app:

We have not integrated a similar thing in the Web UI yet because the ASP.NET platform already provides quite a rich error page where the original problem was less noticeable, at least according to our internal figures.

Notice that the extended error form now  not only displays the top-most error message, but also shows the full call stack for you to research or copy to the DevExpress support crew, if necessary. At the bottom, there is also a link to the new help article describing the most common troubleshooting techniques that should help you save time and hunt "bugs" more effectively. In the majority of cases, these pointers should be sufficient to either research/fix your own custom code or submit an effective ticket to the Support Center, if the underlying issue has something to do with DevExpress routines.

This dialog should NOT appear when no debugger is attached to your app, e.g., when your end-users use your app in production - the former dialog will be shown there to avoid any possible confusion concerning technical details, as in previous versions.

Your feedback is needed!

We hope this will help our users and us to eliminate unnecessary delays and speed up overall problems troubleshooting in Visual Studio. As always, we are also looking forward to hearing from you on this small, but necessary service feature. For instance, to better communicate to developers that it is for development time only, we are also thinking about appending something like " (Debugging...)" to the form title, near the app name or adding some clarification tooltip on mouse hover. Or, is it already clear enough? Please let me know what you think. 

I also welcome other thoughts on solving the original problem in case we overlooked something.

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.