Update target frameworks and package dependencies

[janusw]

This PR updates the target frameworks and package dependencies to an acceptable state.

Concerning the target framworks:

• The .NET Framework versions 4.0 and 4.5 are out of support, and are thus replaced by .NET Framework 4.6.2.
• The .NET (Core) versions 3.1 and 5.0 (also out of support) are replaced by .NET 6.0.

References:

• https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
• https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

Concerning the package dependencies:

• Microsoft.NET.Test.Sdk is updated from 15.0.0 to 17.10.0 (latest stable version).
• NUnit3TestAdapter is updated from 3.8.0 to 4.5.0 (latest stable version).
• NUnit is updated from 3.7.1 to 4.1.0 (latest stable version). This is the only update with breaking changes (fixed via purely mechanical replacments).

All package updates only affect the test project (GeoJSON.Net.Tests), but not the library (GeoJSON.Net) itself.

@xfischer Does this look good to you, or do you have any objections?

[xfischer]

Hi @janusw, thanks for that.

Agreed on dropping out of support .NET versions.
Can you also make the change to support .net8.0 ?

[EDIT : this is done] I was wondering why we use ClassicAssert but realized that it's a big change to adapt all the tests. (we should consider doing it in the future though, maybe via regex replacements as shown here : https://www.aaron-powell.com/posts/2014-02-12-easily-replacing-assert-istrue-statements/ or better via their analyzer here https://docs.nunit.org/articles/nunit/release-notes/Nunit4.0-MigrationGuide.html).

[xfischer]

@janusw I've changed the tests assertions using the NUnit.Analyzer.

[janusw]

@janusw I've changed the tests assertions using the NUnit.Analyzer.

Cool, thanks! I also thought about doing the full migration, but was a bit put off by the effort. I didn't know there was a tool to do it automatically :)

[janusw]

Agreed on dropping out of support .NET versions. Can you also make the change to support .net8.0 ?

I could certainly add a net8.0 target, but I was not sure if it's really necessary. Apps that use net8.0 will certainly work well with the library's net6.0 target. And we already have a rather long list of target frameworks (cf #159).

Btw, one could make the same argument with .NET Framework: We could add net472 and net481 in addition to net462, but is it necessary? I guess we don't gain much as long as we don't use any specific features from the newer versions.

And also, what about the .NET Standard targets?

netstandard1.0;netstandard1.1;netstandard2.0;netstandard2.1

Do we still need them? All of them? Any of them? 🤔

[xfischer]

I could certainly add a net8.0 target, but I was not sure if it's really necessary. Apps that use net8.0 will certainly work well with the library's net6.0 target. And we already have a rather long list of target frameworks (cf #159).

It's not necessary, but indicates that the library has been tested against those newer SDKs.

Btw, one could make the same argument with .NET Framework: We could add net472 and net481 in addition to net462, but is it necessary? I guess we don't gain much as long as we don't use any specific features from the newer versions.

AFAIK, there are no big breaking change. I would suggest dropping .NET Framework support for netstandard20, but leaving at least net462 (ie: netstandard20 on .NET Framework SDK) ensures that it will still work.

And also, what about the .NET Standard targets?

netstandard1.0;netstandard1.1;netstandard2.0;netstandard2.1

Do we still need them? All of them? Any of them? 🤔

• netstandard1.0;netstandard1.1, can be removed (<2.0 means .NET Framework OR out of support .NET Core)
• netstandard2.0 should stay
• netstandard2.1 should stay (may be needed only for Unity support, please anyone suggest here), not needed since .NET5

[janusw]

Do we still need them? All of them? Any of them? 🤔

* netstandard1.0;netstandard1.1, can be removed (<2.0 means .NET Framework OR out of support .NET Core)

* netstandard2.0 should stay

* netstandard2.1 should stay (may be needed only for Unity support, please anyone suggest here), not needed since .NET5

Sounds reasonable, and basically matches the recommendation in https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0#which-net-standard-version-to-target:

If you're targeting .NET Standard, we recommend you target .NET Standard 2.0, unless you need to support an earlier version. Most general-purpose libraries should not need APIs outside of .NET Standard 2.0, and .NET Framework doesn't support .NET Standard 2.1. .NET Standard 2.0 is supported by all modern platforms and is the recommended way to support multiple platforms with one target.

I'm not sure if 2.1 is needed for Unity in any way, but in any case it doesn't hurt to keep it in.

So, I will remove netstandard1.0 and netstandard1.1 then ...

[xfischer]

Looks good, thanks !
Just added 2 comments for testing also against net8.0

[xfischer]

Looks good, thanks !
Just added 2 comments for testing also against net8.0

And sorry I didn't clearly answer on that net8.0 case @janusw. Supporting newer SDKs is always good (even if not required). Now that we have frequent releases of .NET we have to keep up the best we can.
As long as there are no code changes to accommodate that on our code base we should do it. (And doing it does reveal some potential caveats upfront)

Ok with that ?

[xfischer]

@janusw thanks for all this.
Just curious, are you able to merge ? Close the issue ?
I prefer squash and merge to make this one single commit.

[janusw]

@janusw thanks for all this. Just curious, are you able to merge ?

Yes, I see a green merge button, so it seems I do have the necessary permissions (thanks for that).

I prefer squash and merge to make this one single commit.

Actually I'm a fan of a detailed commit history, therefore I dislike squashing and prefer merge commits. 😆

So maybe you just do it your way for now 😉

[xfischer]

Your commits are clean and well named and address one thing at a time so merge is fine !