Can CsvHelper change to netstandard2.1 only?

[JoshClose]

The next version of the parser uses Span<T> and Memory<T> and it more than 5 times faster. These are only available in netstandard2.1 though. I'd like a discussion on how this should be handled.

Here are the options as I see them. Feel free to suggest another option if you have one.

1. Drop everything but netstandard2.1.
   This is the option I'd like to implement. You'll need to convince me why I shouldn't do this.
   • Users that aren't on netstandard2.1 can still use the old packages. They just won't get new features.
   • Bugs fixes could still be implemented into older releases.
   • Only one version to support.
   • No need for #if preprocessor directives.
   • There could possibly be issues with NuGet trying to add a netstandard2.1 only package to projects that aren't netstandard2.1.
2. Create another NuGet package.
   • I'd really like CsvHelper to always be the latest version, so this is not appealing.
   • I don't want to maintain 2 packages.
3. Offer as an opt-in secondary parser.
   • There would be CsvStackParser or something like that. CsvParser would then be deprecated and removed later. When the removal happens, I would want CsvStackParser to be renamed to CsvParser. This could all get confusing.
   • CsvParser could be the new nestandard2.1 only parser and the current parser could be renamed to CsvLegacyParser. I like this route better, but will break most people. Breaking doesn't really concern me all that much though because it will be a major version change.
   • Unit tests would somehow need to be updated to run both parsers.
4. Use the new parser for netstandard2.1 and the old for everything else.
   • This would hide bugs and confuse people.

[StefanBertels]

I vote for (1), i.e. netstandard2.1 only.

[PatrickHofman]

Option (1) definitely. Take the pain once, also for the users implementing this and wanting new features. Everyone else, stay on the old version.

The performance gain is impressive. Good work!

[monty241]

.NET standard is a set of api's as far as I know, implemented in some piece of software. Since all .NET Core releases have already reached end of support except 2.1 and 3.1, I would recommend sticking to 2.1.

So option (1)

See https://dotnet.microsoft.com/platform/support/policy/dotnet-core

[jongleur1983]

We use a quite old version (and are fine with that) as nobody cared to update it while checking if nothing breaks.
As we didn't update for a long time, I'd support option (1) as well - once we can switch to Core (in the WPF world) we'll have to tackle the upgrade nevertheless, and it's unlikely we'll do it earlier.

[mudnug]

Does anyone know if there is a tool that can list all opensource projects that depend on CsvHelper and show what percent support netstandard2.1?

[PatrickHofman]

@mudnug I don't see the relevance of that, since those projects can still use the old version if they want to. There is no need to update. And all packages eventually upgrade their framework, so no need to be afraid of breaking anyone's project.

[JoshClose]

I agree with @PatrickHofman but I found these 2 sites.

https://nugetmusthaves.com/Dependency/CsvHelper

https://libraries.io/nuget/CsvHelper/dependents

[c0shea]

I'm ok with option 1 so long as bugs that apply to the latest non-.netstandard 2.1 version are backported. We're on .NET Framework 4.8.

[JoshClose]

If they apply to both, then they would be.

[istrupin]

Option 1 with backported bug fixes sounds ideal and would definitely get my vote.

[twelsh920]

Any update on this? Really looking forward to the potential performance improvements you've mentioned elsewhere that use the newer Span<T>, Memory<T> apis

[JoshClose]

This was done in version 19. The speed improvement was huge and it's not using span/memory. Still compatible with .NET 4.5

https://www.joelverhagen.com/blog/2020/12/fastest-net-csv-parsers

[JoshClose]

It's going to be a bit still. This feature requires refactoring of most things.