Fixes #224

[PhyxionNL]

No description provided.

[claassistantio]

All committers have signed the CLA.

[ejsmith]

Thank you! I agree that this lib should not reference winforms. I haven’t dug in much yet, but should we be wiring up for unhandled exceptions in some other way? https://stackoverflow.com/questions/793100/globally-catch-exceptions-in-a-wpf-application

[niemyjski]

Can we put all this existing code against a Net45 existing compiler directive. I was thinking about this more, there are some wpf apps like our own that has winforms interop and bringing in a new client I think would be breaking.

[PhyxionNL]

Thank you! I agree that this lib should not reference winforms. I haven’t dug in much yet, but should we be wiring up for unhandled exceptions in some other way? https://stackoverflow.com/questions/793100/globally-catch-exceptions-in-a-wpf-application

I think DispatcherUnhandledException is enough (along with base), but it's now using one static field so you can only use one client. I doubt there are many cases of people using multiple clients though. For now this change is enough for the issue, the other things can be done later if needed.

@niemyjski WPF shouldn't load the WinForms libraries just for ThreadException (only causes more assemblies to get loaded), and most WPF apps don't use WinForms.

[niemyjski]

On full framework it doesn't really matter if WinForms is loaded does it? It's apart of the official runtime. I know our commercial app does both winforms and wpf and it's nice knowing both is covered. It would be nice knowing legacy full framework keeps on working and newer implementations (core) has an updated behavior.

[PhyxionNL]

On full framework it doesn't really matter if WinForms is loaded does it? It's apart of the official runtime. I know our commercial app does both winforms and wpf and it's nice knowing both is covered. It would be nice knowing legacy full framework keeps on working and newer implementations (core) has an updated behavior.

It matters also for full framework because the WinForms assemblies must get loaded from disk, this is not necessary for most WPF application because they don't use WinForms. For applications that actually need a dependency on WinForms it would be as simple as adding Exceptionless.Windows and calling that one additional Register... method on the client (I've tried, it works). Or if that somehow would be too troublesome (doubt it) another platform could be added that combines these, but WinForms doesn't belong in WPF (WinForms doesn't do this for WPF either).

[niemyjski]

Thanks for the PR!