Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only support .NET Standard 2? #145

Open
304NotModified opened this issue Jun 27, 2022 · 6 comments
Open

Only support .NET Standard 2? #145

304NotModified opened this issue Jun 27, 2022 · 6 comments
Milestone

Comments

@304NotModified
Copy link
Member

No description provided.

@304NotModified 304NotModified modified the milestones: 4.0, 3.0 Jun 27, 2022
@304NotModified 304NotModified changed the title Only support .NET Standard 2 Only support .NET Standard 2? Jun 27, 2022
@304NotModified
Copy link
Member Author

304NotModified commented Jun 27, 2022

this is a bit pity with those dependencies...

image

@rstm-sf
Copy link
Collaborator

rstm-sf commented Jul 10, 2022

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

@adimosh
Copy link
Contributor

adimosh commented Jul 11, 2022

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).

@rstm-sf
Copy link
Collaborator

rstm-sf commented Jul 17, 2022

@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)

@304NotModified
Copy link
Member Author

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

@304NotModified
Copy link
Member Author

Ps. I'm OK with .net standard 2 + .net 6. Implicitly we support .net 4.7.2 then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants