> Deciding whether something is netFramework 4.8 or .NET Core 5 or NET3000 or nEt5 or NET Common 2.0 is impossible.
Is it, though? The guidelines seem to be pretty straight forward: unless you want to target a new language feature, you can just target netstandard or whatever target framework your code requires at the moment. This barely registers as a concern.
https://learn.microsoft.com/en-us/dotnet/standard/net-standa...
> It's okay to read, but basically impossible to write by hand.
Are you sure about that? I mean, what's the best example you can come up with?
This complain is even more baffling considering a) the amount of XML editor helpers out there, b) the fact that most mainstream build systems out there are already XML-based.
I personally wouldn't bother with .NET Standard anymore. .NET Standard 2.0 is nicely frozen and still useful to some legacy shops, but at this point I think for all new code the only decision is to support LTS or not, and then just pick the latest version.
It will break in a year when a new shiny version appears.
.NET Standard 2.0 will break? I think it's frozen for good. That's also the biggest problem with it: there are so many performance improvements in .NET 7+ that .NET Standard can't opt into but come "free" with retargeting. (Among other things, a lot more Span<T> overloads throughout the BCL. There is a compatibility shim for Memory<T> and Span<T> access in .NET Standard 2.0 and that also includes some of the new overloads, but not all of them.)
Targeting a specific .NET version will break in a year? LTS versions specifically have two years of support. But also .NET has very rarely broken backward compat and you can still easily load libraries built targeting .NET 5 in .NET 9 today. You don't necessarily have to "keep up with the treadmill". It's a good idea: see "free performance boosts when you do". But it isn't required and .NET 5 is still a better target from today's perspective than .NET Standard 2.0. (The biggest instance I know of a backwards compatibility break in .NET was the rescoping between .NET [Framework] 3.5.x and .NET [Framework] 4.0 on what was BCL and what was out/no longer supported and that was still nothing like Python 2 versus 3. I know a lot of people would also count the .NET Framework 4.x and .NET Core 1.0 split, too, which is the reason for the whole mess of things like .NET Standard, but also .NET Standard was the backward compatibility guarantee and .NET Standard 2.0 was its completion point, even though yes there are versions > 2.0, which are even less something anyone needs to worry about today.)
AFAIK, net5 and net9 are incompatible with each other and you can't run one on another, major versions and all that. You need netstandard to run on different versions, but it's only for libraries, you can't run a process on netstandard.
.NET 9 will absolutely load a library that was built targeting .NET 5.
For instance, GraphQL was built targeting both .NET 5 and .NET Standard 2.0, as you can see towards the top of the NuGet page: https://www.nuget.org/packages/GraphQL
.NET 9 will use the .NET 5 build, not .NET Standard 2.0. (.NET Framework 4.8.x would use .NET Standard 2.0.) Because .NET 5 > .NET Standard 2.0.
Or Automapper 14 targets only .NET 8: https://www.nuget.org/packages/AutoMapper
It runs on .NET 9 and .NET 10.
Just to pick two examples at mostly random from the top packages on NuGet.