Diagnostic tool for Security System - YOUR FEEDBACK IS NEEDED!!!

Earlier we described the prototype of diagnostic tool. We created it to help a developer to understand why access to a certain object and its members is allowed or denied.  

  

We analyzed the feedback we got on this matter and provided the following improvements in v17.2.6:

 - To enable the security diagnostic tool, use the familiar EnableDiagnosticActions option.

 - You can select a type and a member you wish to analyze.

 - Results are presented in the XML format.

 - We provide more details on how the diagnostic tool calculates results.

 - There is a way to visualize criteria for easier analysis.

You can get more info about the tool from the KB article below:

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

Your feedback is needed

Please test the tool and let us know whether it is useful in your development process and how you would change it. For instance, the more specific there are use cases of this tool where it was difficult to configure permissions for a user, the greater it is possible that we can arrive at technical solutions that will address them.

How to diagnose effective access rights for a specific user or get full information about inner security permissions calculations

Security permissions calculation is quite a complex process, and sometimes it is difficult to diagnose why access to a certain object and its members is allowed or denied. It is more common for application administrators or regular XAF developers who may not want to study documentation guides or be able to debug the XAF source code as per How can I debug DevExpress .NET source code using PDB files or using other approaches. So, in addition to documenting security rules, we are researching the usefulness of a tool that would show how effective permissions are calculated for each user in the UI, very similar to our Diagnostic Action. This may be helpful even to us, to reduce support time spent on diagnosing related client problems.

Learn more about a possible solution (a diagnostic tool) from the KB article below and let us know what you think:

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

As for other wish list and scenarios, you can help us by filling out the following survey, if you haven’t done so already:

https://www.devexpress.com/go/XAF_Future_Survey_2017_Dec.aspx

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

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.

How to find and deactivate a problematic Controller "on the fly" via an application UI for troubleshooting purposes

I wanted to repost a troubleshooting tip our old XAFer and MVP Dave Hesketh has kindly provided in the Support Center today. BTW, Dave also provides XAF training and custom development services, based out of Ontario, Canada, so this may be not the last thing you would want to learn from him and his website. 

So, let me focus on the problem and solution he described at https://www.devexpress.com/kb=T433881 and also also quickly show it all in action with one of the XAF demos:

"I have come across a few scenarios where something seems to be slowing down an XAF solution and it is tough to determine where the issue exists. This can then lead to hours of tearing out controllers to try and determine if one is problematic.

To make this process easier, I have created a module that you can add to an XAF solution to Enable and Disable controllers on the fly.

Once you add this module to your solution, you will find the "Show Controller Settings" action in the Tools menu. In the dialog that appears, you can enable or disable any controllers you wish, or click the "Disable Custom Controllers" to disable non-DevExpress controllers (A good starting place). 

Please note: Once you enable or disable controllers, you must re-open a view for the change to take effect. This solution has been tested on existing Win Applications only."

I remember a couple of similar requests from other guys, and indeed, this dynamic exclusion of Controllers without recompiling and restarting the whole app can be helpful when researching certain complex problems like performance or behavioral/visual side effects. For many other cases, the built-in Diagnostic Action, application log files, and performance profilers would suffice pretty well. 

Anyway, let's check how to use Dave's module with our MainDemo.Win app. Consider the following steps: