Only support .NET Standard 2?
304NotModified opened this issue · comments
this is a bit pity with those dependencies...
It seems to me that we can leave the legacy framework and netstandard2.0 (net40; netstandard2.0). The output folder, e.g. for net60, will not contain this dependency
AS per @rstm-sf 's request, I am forwarding here my argumentation on explicitly targeting things:
The reason I advocate targeting net462;net472;netstandard2.0;net6.0 in the #158 pull request has to do with package resolution.
If I have a library that targets .NET Framework 4.6.2 (lowest supported framework version, which, unless Microsoft says otherwise, appears scheduled to be supported until January 12th, 2027), and I only have a netstandard2.0 target, it will pollute the output with a lot of libraries that mostly do type forwarding, as .NET 4.6.2 didn't quite achieve that perfect bond of framework and standard that would allow it to not need type forward libraries. So, in order to only have exactly what you need, you should offer a net462 target. Rick Strahl talks about this in a blog post in 2019.
The first to fully support netstandard2.0 properly was .NET Framework 4.7.2, which can handle netstandard2.0 quite well. However, here's where the tricky NuGet package resolution comes in: if you have a net462 target in your package, that one will be loaded before netstandard2.0 in your net472 or net48. So, in order to get the best and latest features (which you may want? I don't know, just keeping all options open!), it is worth adding a net472 target as well. The package is not huge, so it won't make that much of a difference.
Last, net6.0. I have included this specifically as the CodePages library has changed with .NET 6 in a version of its own. Microsoft has claimed to make a lot of improvements ("the fastest .NET yet" and such), so I added this target specifically as it is the current (and so far only) LTS version that has breaking package management changes. So, I thought, for better package management in the projects of whoever uses your library, there is an explicit target which allows projects only targeting most modern .NET version to not have to bother about any past relics of packages long forgotten.
I have compiled a list of supported frameworks and dates on a personal page for convenience (albeit for an entirely different purpose).
@adimosh, thanks!
In fact, the only dependency in this library is the System.Text.Encoding.CodePages (since this is the only thing that is specific to this library at the moment). It is not necessary when we have a legacy target, so for net40-net48 it will not be added and it makes sense to leave any of the legacy targets. For the core version, it also does not make sense to add the nuget package, since it has been added to the SDK with .NET Core 3.0. Also, the library is trimmed if added explicitly to PackageReference and has the latest version specified in the SDK. As for UTF-7, it was not even added to System.Text.Encoding.CodePages and is included in BCL if we specify the EnableUnsafeUTF7Encoding property https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/utf-7-code-paths-obsolete
So I think it makes sense to leave net40; netstandard2.0 (maybe add some more or replace legacy to support async)
I think people should stop using .net framework < 4.7.2. And IMO also the whole .net framework stuff. Yes it supported by Microsoft, but users could also use the old version.
.net framework < 4.7.2 is at least 4 year old tech! See
https://endoflife.date/dotnetfx. The first .net core RTM is 6 years old. https://endoflife.date/dotnet
Ps. I'm OK with .net standard 2 + .net 6. Implicitly we support .net 4.7.2 then.