Drop extremely outdated TFMs

[Youssef1313]

As of today, it looks like BDN supports back to netcoreapp2.0 which is out of support since October 2018, that's 7 years, and can be very limiting. See Youssef1313/YTest.MTP.XUnit2#12 for example.

[timcassell]

BDN targets netstandard2.0, netcoreapp2.0 support is simply a by-product of that because it supports the tfm. We don't explicitly target core tfms older than net6.0. So I'm not really sure what the ask is here.

[Youssef1313]

@timcassell There are test projects that explicitly target old TFMs like netcoreapp2.0.

BenchmarkDotNet/tests/BenchmarkDotNet.IntegrationTests.ManualRunning.MultipleFrameworks/BenchmarkDotNet.IntegrationTests.ManualRunning.MultipleFrameworks.csproj

Line 6 in 7bd81aa

<TargetFrameworks>net461;net48;netcoreapp2.0;net8.0</TargetFrameworks>

Plus some production projects also target old TFMs like netcoreapp3.1:

BenchmarkDotNet/src/BenchmarkDotNet.Diagnostics.dotMemory/BenchmarkDotNet.Diagnostics.dotMemory.csproj

Line 4 in 7bd81aa

<TargetFrameworks>net8.0;net6.0;net462;netcoreapp3.1</TargetFrameworks>

BenchmarkDotNet/src/BenchmarkDotNet.Diagnostics.dotTrace/BenchmarkDotNet.Diagnostics.dotTrace.csproj

Line 4 in 7bd81aa

<TargetFrameworks>net8.0;net6.0;net462;netcoreapp3.1</TargetFrameworks>

[timcassell]

The test project is inconsequential to release packages, it's there just to make sure we don't accidentally break any runtimes that actually support netstandard2.0 (and we don't even run it in CI, it's a manual test).

As for the dotMemory and dotTrace packages, I'm not sure, but in general the philosophy here is we don't explicitly remove support for runtimes unless there's a very good reason to. cc @AndreyAkinshin

@filzrev previously mentioned migrating from XUnit to TUnit that actually supports netstandard2.0, which I think is reasonable and should negate the need for the linked issue.

[Youssef1313]

The test project is inconsequential to release packages, it's there just to make sure we don't accidentally break any runtimes that actually support netstandard2.0 (and we don't even run it in CI, it's a manual test).

That can be done with a little bit newer TFM like net7.0. I don't think it's worth doing the validation for netcoreapp2.0/netcoreapp3.1.

@filzrev previously mentioned migrating from XUnit to TUnit that actually supports netstandard2.0, which I think is reasonable and should negate the need for the linked issue.

I'm honestly not sure if it's guaranteed to work. There can be many transitive dependencies that will compile fine with netstandard2.0, but will start producing warnings when they are used in old .NET versions. Would you be fine suppressing those warnings and just hoping for the best?

[Youssef1313]

Would you be fine suppressing those warnings and just hoping for the best?

Looks like you already do it:

BenchmarkDotNet/build/common.props

Lines 27 to 28 in 2c92629

	<!-- Suppress warning for nuget package used in old (unsupported) tfm. -->
	<SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings>

[AndreyAkinshin]

Thanks for bringing this up. I took a closer look at our TFM targets across the repo and I agree that some of them are long overdue for cleanup.

Tim is right that our broad runtime compatibility comes from targeting netstandard2.0 in the main package — users on older runtimes get that fallback automatically without us explicitly targeting dead TFMs. That said, there are a few places where we do target outdated runtimes directly, and it's worth addressing those.

Regarding the specific request:

The ManualRunning.MultipleFrameworks test project can be updated. Targeting net461 and netcoreapp2.0 there doesn't provide real value:

• net461 has known issues with netstandard2.0 consumption — Microsoft themselves recommend net462 as the practical minimum (and ideally net472+).
• netcoreapp2.0 has been EOL for 7+ years. Since this test project doesn't run in CI, keeping it there creates an illusion of coverage rather than actual validation.

I'm fine with updating that project to net462;net48;net8.0 (and potentially adding net10.0).

As for dotMemory/dotTrace targeting netcoreapp3.1 — this is constrained by the JetBrains.Profiler.SelfApi dependency, which targets netcoreapp3.0 as its minimum .NET Core TFM (no netstandard2.0 support). We need netcoreapp3.1 in the target list to maintain a valid NuGet fallback for users on net5.0–net7.0. This can be revisited when JetBrains updates their package.

General thoughts on TFM support policy:

Our main package (BenchmarkDotNet) targets netstandard2.0 + specific modern TFMs for API access. The netstandard2.0 target is what gives us broad runtime compatibility — users on old runtimes get that fallback automatically. We don't need to explicitly target dead runtimes to support them.

For test/sample projects, I think the reasonable minimum going forward is:

• net462 for .NET Framework (the oldest version that properly supports netstandard2.0 and is still in support until Jan 2027)
• net8.0 as the current LTS baseline
• net10.0 for latest runtime validation

There's no practical reason to test against runtimes that have been out of support for years and that we have no CI coverage for.

[Youssef1313]

As for dotMemory/dotTrace targeting netcoreapp3.1 — this is constrained by the JetBrains.Profiler.SelfApi dependency, which targets netcoreapp3.0 as its minimum .NET Core TFM (no netstandard2.0 support). We need netcoreapp3.1 in the target list to maintain a valid NuGet fallback for users on net5.0–net7.0. This can be revisited when JetBrains updates their package.

I don't see why netcoreapp3.1 is needed? If your packages declare their minimum as net8.0, they can still consume the JetBrains library that's built with netcoreapp3.1. I don't think that makes the NuGet package invalid in anyways. It will definitely mean that users on net7.0 or earlier will no longer be able to consume the BDN package, but those TFMs are not supported, and users should react and update (IMO).

[AndreyAkinshin]

You're right — I overstated the JetBrains constraint in my previous comment. The netcoreapp3.1 target in dotMemory/dotTrace is a backward-compatibility choice, not a technical requirement imposed by JetBrains.Profiler.SelfApi. A net8.0 build consumes the netcoreapp3.0 assets from JetBrains just fine.

There's also no conditional compilation (#if) in either diagnostic package — all four TFM builds produce functionally identical code. So the only effect of the extra targets is widening the set of runtimes that can resolve a compatible NuGet asset.

Given that netcoreapp3.1 (EOL Dec 2022) and net6.0 (EOL Nov 2024) are both out of support, I'm fine with trimming dotMemory/dotTrace to net8.0;net462. This brings them in line with the rest of the repo — net462;net8.0 is already the established baseline across 10+ test projects, samples, Disassembler, and TestAdapter. Users on unsupported runtimes can pin the previous package version.

Regarding the main BenchmarkDotNet package — it also targets net6.0, but dropping it there is a bigger change. Unlike dotMemory/dotTrace, the main package has a netstandard2.0 fallback, so net6.0/net7.0 users wouldn't lose access entirely. However, they'd silently fall back from the net6.0 build to netstandard2.0, losing ~26 NET6_0_OR_GREATER code paths (hardware intrinsics detection via System.Runtime.Intrinsics, direct GC.GetTotalAllocatedBytes instead of reflection, etc.). That deserves its own discussion.

@Youssef1313 @timcassell