Do we still want to keep older .NET versions?

[Protiguous]

I'm now seeing this warning on compile in my experimental branch.

warning NETSDK1138: The target framework 'net5.0' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

Microsoft's Download .NET 5.0 reads:

This release has reached end of life, meaning it is no longer supported. We recommend moving to a supported release, such as .NET 7.0. See our support policy for more details.

I don't see any problem with leaving it available, except for the possibility that a security flaw might be discovered in .NET 5.
I will continue to work with .NET 5 until I hear otherwise.

[AdamWhiteHat]

Naw, there is no need to stay on .NET 5. Feel free to upgrade it and submit a PR, or if that's a bit of a hassle because of changes made in your fork/branch then lemme know and I can git 'er don

[AdamWhiteHat]

Scratch that. Yeah, lets keep it.
I'm making all my math/numeric libraries have the same set of target frameworks, and this set includes .NET 5.

The reason I'm making all my libraries support the same set of target frameworks is because I have a 'generic arithmetic' library that performs arithmetic on the generic type T, which my GenericPolynomial and GenericMultivaritePolynomial libraries use, and the test projects for these generic polynomial libraries take a dependency on BigDecimal, BigRational, BigComplex, and so on and its hard to test against a target framework unless all these libraries also target it, so I'm standardizing the set of target frameworks across all of them.

In regards to security, I think it is unlikely that anything we are doing is going to result in a security problem; we are not deserializing arbitrary data, we are not writing to the filesystem or making system API calls, we are not elevating privileges and we are not using pointers or unsafe code or anything like that, so I think the risk is low.

[Protiguous]

I can understand the desire to keep a consistent set of frameworks supported across a set of projects.
But coding around the issues in older versions like net45 and net46 are hampering writing better code because of all the missing features.
Also, these old versions do not contain any of the myriad of performance improvements from the newer frameworks.

@AdamWhiteHat, Are you okay with removing net45 and/or net46 support from BigDecimal?

[Protiguous]

Whoa. I just noticed there are now "Transitive" nuget packages listed.
If these are making a feature backwards-compatible, then these older net45 and net46 might not be such a hassle!

[Protiguous]

Hmm. Taking another look at these transitive NuGet packages. I am still uncertain whether they deliver the desired outcome.

[AdamWhiteHat]

I thought the library was more-or-less in a state of done and didn't need to change much.
What new language features are you wanting to use that .NET 4.5 doesn't support?

Its a shame that my versioning is a bit unruly. It would be nice if one could tell from the version what version of .NET the library supports..

Yeah im not sure how Transitive NuGet packages help in this particular situation.

[Protiguous]

I still can't determine what these transitive NuGet packages offer. I was hoping for backwards compatibility.

I'm looking to standardize the constructors, and optimize with a LazyCache any calculations that are expensive or may be repeated often.
I have written a lot in a local branch, but I believe I should introduce each feature in small increments and ensure all tests work.
(Those new trig-tests take a lot of time! I'll see what I can optimize there also.)

Are you more comfortable with approving each small pull request, or with me pushing compatible incremental updates to main/master to save time on my end? I tend to program in bursts when I have time.

[Protiguous]

It would be nice if one could tell from the version what version of .NET the library supports.

The output bin folders are different (\Debug\net45, \Debug\net46, \Debug\net462, etc).
Do you mean like appending, “-net45” onto the filename?

As in, “ExtendedNumerics.BigDecimal-net45.dll”?