Drop .NET v3.5 support?

[iamcarbon]

With the upcoming wave of memory features (Span<T> and friends) coming to .NET, it may be a good time to drop support for .NET v3.5 (released over 10 years ago) to pave the way for adoption. This also eliminates the need to install the .NET3.5 targeting pack to open and contribute to the project.

There's been a handful of big projects dropping support for .NET v3.5 recently including Math.NET Numerics.

I've can send a PR if this is reasonable.

Thoughts?

[kwhopper]

I tend to agree. Windows 10 1709 (Fall Creators Update) is shipping with 4.7.1 by default, and 3.5 support (actually, 2.0 since 3.x doesn't have the CLR) is only necessary for Windows Vista and below. Windows 7 can install any version of the framework through the latest. That said, 4.5.1 and below of 4.x are no longer supported by Microsoft, so if any change is made we would need to carefully consider which version of 4.x will be supported in this project. Perhaps it's easy enough to just say 4.x is the target.

We should consider the same with XMPCore, although it's less of an issue as a utility project.

[drewnoakes]

Definitely keen to kick the tyres properly on the upcoming memory features. This project is a good fit for that. Has there been a commitment on the back-porting of spans to current CLRs? As I understand there are two variants, one fast (two-field) one slow but backwards-compatible (three-field).

The inability to build without the targeting pack is also a nuisance. On my machine dotnet build fails, but the Build.ps1 script succeeds. I haven't looked into why.

I'd be happy to start a 2.1 branch for a future release that would drop net35 support. In that sense, 2.0 would be the last version to support net35. A PR would be very welcome!

[twest820]

I'm good with dropping the 3.5 build and just continuing with 4.x. According to Microsoft, Vista is updateable to .NET 4.6 so also bumping the 4.5 project forward a step wouldn't necessarily block Vista users.

On the projects I'm involved in which consume Metadata Extractor we recommend 4.7.1 but support back to 4.6.1 for now. My guess is we'll probably on 4.7 by the time Metadata Extractor 2.1 is ready, though that may change as release schedules become more clear. The last one of those dropped Vista support a couple years ago.

(Another major project close to finally dropping 3.5 is WIX, probably a few months from now.)

[twobob]

there are plenty of uses for this in scenarios that force the use of 3.5. Tiny devices, Games, Devices with welded in immutable libraries. However it's your project and obviously there are benefits.
Good to hear you aren't just utterly ditching the support for those people who have the most limiting options.

[patricksadowski]

I've prepared a branch to drop support for 3.5. Which branch should the PR target?

[drewnoakes]

Revisiting this, I'll consider dropping net35 in version 3.0 if it turns out that using spans makes enough difference to performance to warrant leaving some percentage of users behind. Historically both the .NET and the Java implementations of the library have maintained support for very old frameworks.

The API will likely change considerably for 3.0. I won't merge any PR for that just yet, sorry @patricksadowski. When we do drop net35 I'll try to remember to pull your commit in, assuming it merges well at that time.