net5.0-windows

[makeProjectGreatAgain]

This PR will update the ExceptionReporter.NET to support the net5.0-windows TargetFramework

I have tested it manually and all seems OK. Also, I have run UnitTests for net5.0-windows and 2 of them were red:

1. • [x] Can_Dig_Assembly_Refs_By_Name() - I assume it was false negative. This test checked the existence of "System.Core" but it wasn't necessary(?)
2. • [ ] Can_Render_Text_Template_Baseline_1_Of_Everything() - the problem is in Handlebars 2.0.2. There are newer versions of Handlebars, but them had more bugs (more failed unit tests). Later I will report about it to the maintainers of Handlebars

---

• [ ] problem with the ApplicationDeployment API in Net5

[makeProjectGreatAgain]

I used Simple-MAPI.NET netstandard2.0 version from this PR Simple-MAPI.NET netstandard2.0 target framework

[PandaWood]

Thanks yeah, I should pull in the netstandard2 PR from SimpleMAPI first and then come back to this one

[PandaWood]

I noticed a lot of people are missing the ApplicationDeployment API in Net5, they're tracking the issue here (we use it twice in ER) https://github.com/dotnet/deployment-tools/issues/27

One user's solution is this

I noticed he replaces ApplicationDeployment.IsNetworkDeployed with basically (in summary) AppDomain.CurrentDomain.SetupInformation.ApplicationBase.Contains("AppData\\Local\\Apps")

If we could write something like that, conditional on NET50, maybe...

[PandaWood]

Actually, reading this MS blog, I get the idea that the most practical option here is to target .netstandard 2.0 - to basically support both .NetFramework and .NET5

https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/

If you’re building reusable libraries that you plan on shipping on NuGet, you’ll want to consider the trade-off between reach and available feature set. .NET Standard 2.0 is the highest version of .NET Standard that is supported by .NET Framework, so it will give you the most reach, while also giving you a fairly large feature set to work with.

[makeProjectGreatAgain]

Actually, reading this MS blog, I get the idea that the most practical option here is to target .netstandard 2.0 - to basically support both .NetFramework and .NET5

There is a dependency on WinForms therefore it can't be targeted on .netstandart 2.0