Feature request: include additional custom data in the generated report

[CrushaKRool]

Hi, it would be nice if there was a way to supply additional data to the exception reporter. This may be contextual state information that the application has available (and which is not included in the thrown exception) that could help in analyzing the issue.

Perhaps this could be passed in as additional string parameter of the Show() method. If supplied, it could then be shown in a separate tab of the UI and would also be included in the different outputs that can be generated.

[PandaWood]

Thanks, yes there's already an override of Show() with a string for CustomMessage, but this custom data proposal of yours will be different for each exception, so yes we'd have to expose in the Show(), I think.

If we also add it to the ExceptionReportInfo (config) class then we can cater for the dialog-free technique of using the ExceptionReportGenerator class, ie without the Show() method.

[CrushaKRool]

Yeah, the CustomMessage is not included in the generated reports, so it wouldn't be much use to the developers receiving the report.

Personally, I tend to set CustomMessage to a combined list of the message of the exception and its inner exceptions. (Basically a condensed stacktrace without the actual code references)
While the users may not have as much use for it as developers, they still might get an idea about what exactly is going awry and whether its something they should report or could fix on their own when that window pops up.

I was pondering whether it might be a good idea to just pass a Function delegate to the ExceptionReporter and let it retrieve the custom data that way. However, such a delegate would then probably be limited to what data is globally accessible, rather than getting it from the current thread of execution. Both would work in my scenario, but I guess a simple parameter is more suitable for the majority of use cases.

[PandaWood]

Yes, we could make the custom data a string (that might confused the Show() method overrides...
or an Object (that we call ToString() on it)
or we could make our own class for it, just to make the API explicit (class CustomData) that you have to instantiate
or we could just make it an interface ICustomData, with a ToString() assumption but then add whatever you need...

[PandaWood]

... or a Function delegate as you mentioned...

[PandaWood]

Actually, I'm also in the middle of a large refactor in the design of the classes that "Send"
MailSender/SmtpSender/WebServiceSender/MapiSender
https://github.com/PandaWood/ExceptionReporter.NET/compare/isender

So I might have to hold off on some of these changes.
But all your thinking is correct on the separation and design.

[PandaWood]

BTW I was able to compile this project on Mono/Mac until a few days ago when we added support for ClickOnce deployed applications. Checking the version on a deployed application requires an assembly reference that Mono has absolutely no support for, so sadly, cross-platform support is now impossible. Especially since the latest mono compiler removed conditional compilation. There's just no way to compile it now

[PandaWood]

And Xamarin is owned by Microsoft and is now "Visual Studio for Mac" - which is what I'm using. So nothing changes I'm afraid ;-)

[SlyFoxHayes]

We can take support for ClickOnce out, and just provide a code example of how to populate the AppVersion with the ClickOnce version (I started out this way). Or create a ClickOnce only assembly and NuGet release (i.e. ExceptionReporter.NET.ClickOnce), that uses ExceptionReport.NET as a dependency. Admittedly, a whole new NuGet project for what ultimately amounts 2 two lines of code to get the ClickOnce Version seems like overkill. <removed email trail>

[PandaWood]

I'm OK with the ClickOnce support. There's a lot of other code that wouldn't run under Mono either - the system information gathering, the screenshot taking.

I put code in to check for Mono and not run those bits of code.
A few months ago, I could run the ExceptionReporter under Mono, but the UI was "frozen" - Mono only has limited support for WinForms.

As of a few months ago, Mono just crashes without showing the dialog. Nothing we changed.