Goal

As part of the 4.0 major release, replace the current target-framework set with a smaller, modern set. This removes a large amount of dead-platform surface, simplifies the build and dependency graph, and positions the driver for Unity's move to CoreCLR — while being deliberate about the one live platform this drops (current Mono-based Unity).

Proposed change

This is a breaking change and is only appropriate for a major version.

Why

1. Drops a large amount of out-of-support surface, making the support story much cleaner.

Everything removed below is already end-of-life, except current Mono-based Unity (called out separately):

• netstandard2.1 unique consumers: .NET Core 3.1 (EOL), .NET 5/6/7 (all EOL), Xamarin (EOL May 2024), standalone Mono ≤ 6.x (niche/legacy), and current Mono/IL2CPP Unity (the one live casualty — see below).
• net6.0 — EOL Nov 2024.

Removing netstandard2.1 and net6.0 also lets us delete polyfill package references and dead #if NETSTANDARD2_1 branches (8 sites), shrinking the maintained matrix to 3 modern targets with far less conditional code.

2. Retains modern MAUI / mobile support.

.NET MAUI and mobile target heads (net8.0-ios, net8.0-android, etc.) resolve the base net8.0 asset — the driver has no platform-specific code that requires dedicated mobile TFMs. MAUI support is unaffected.

3. Prepares for modern (CoreCLR) Unity support.

Unity is replacing Mono with CoreCLR: the CoreCLR desktop player arrives in Unity 6.7 and full editor integration in 6.8, bringing .NET 10 / C# 14 (6.8 alpha expected late 2026, stable ~2027). Once a Unity project is on 6.7+, it consumes the driver's net10.0 asset natively — no netstandard, no Mono. On CoreCLR the long-standing Unity pain points disappear (notably the SCRAM crypto gap below is CoreCLR-native). So this target set delivers future Unity support for free, with no Unity-specific work. This aligns with the Unity epic (CSHARP-5178), whose current timeline (FY27Q3) overlaps Unity's CoreCLR GA.

What is supported vs dropped

Supported: .NET Framework 4.7.2/4.8/4.8.1 (net472); .NET 8 LTS (net8.0); .NET 9 (via net8.0 fallback); .NET 10 LTS (net10.0); .NET 11+ (via net10.0 fallback); .NET MAUI / mobile (via net8.0); future Unity 6.7+ CoreCLR (via net10.0).

Dropped: .NET Core 3.1, .NET 5/6/7, Xamarin, standalone Mono (all EOL); current Mono/IL2CPP Unity (Unity 6.0–6.6, 2022.3 LTS) — the only live platform lost.

Downside: this drops current (Mono-based) Unity support — and retaining it is costly

The single meaningful casualty is today's Unity, which runs Mono (desktop/server) or IL2CPP (AOT). Attempting to keep supporting it in 4.0 is significantly more expensive than it looks, primarily because of SCRAM, the default authentication mechanism:

• SCRAM depends on a .NET Framework 4.7.2 crypto API. Both ScramSha256Algorithm.cs:67 and ScramSha1Algorithm.cs:35 call new Rfc2898DeriveBytes(byte[], byte[], int, HashAlgorithmName) unconditionally. That constructor overload was added in .NET Framework 4.7.2 and is not in the netstandard2.0 contract (it's netstandard2.1+).
• A netstandard2.0 Unity target would not even compile without a hand-rolled PBKDF2 (HMAC-based) fallback added to the auth hot path — new crypto code we'd have to write, test against RFC vectors, and maintain.
• Even keeping netstandard2.1 (or net472) does not guarantee Unity works at runtime. Mono's mscorlib (the Rfc2898DeriveBytes in Mono's .NET Framework profile) appears to lack the HashAlgorithmName constructor entirely. If Unity's shipped Mono matches upstream, then SCRAM throws MissingMethodException at first authentication — the assembly loads fine, but username/password auth (the Atlas default, what nearly everyone uses) fails. This affects the net472 and netstandard2.1 assets equally, and is a likely relative of CSHARP-5725 ("C# driver stopped working with Unity since v3.2.0"). (Unverified against Unity's specific Mono fork — but the source strongly suggests it.)
• Consequence: genuinely supporting current Unity means either (a) shipping an in-driver PBKDF2 implementation so SCRAM stops calling the missing BCL method on Mono, or (b) telling Unity users to avoid SCRAM entirely and use X.509 / OIDC / AWS. Non-SCRAM auth (X.509 especially, which Atlas supports) is a valid workaround, but it is not the default and shifts real setup burden onto users.
• Packaging pain on top of that: Unity can't restore NuGet, so any legacy asset must be hand-imported with its full transitive dependency graph (or via NuGetForUnity).
• Poor ROI given timing: all of this Mono-specific investment has a shelf life ending when Unity users move to CoreCLR (6.7/6.8, ~2027) — the same window the Unity epic would ship in. We'd be building support for a runtime Unity is actively removing.

Recommendation: accept the drop of current Mono Unity in 4.0. Serve future Unity natively via net10.0 (CoreCLR), and treat current Mono/IL2CPP Unity as documented best-effort (use X.509/OIDC) rather than a first-class netstandard + PBKDF2 build. Reconsider only if CSHARP-5178 explicitly requires supporting today's Mono-based Unity user base before CoreCLR GA.

Acceptance criteria

• src/Directory.Build.props targets net472 ; net8.0 ; net10.0.
• Polyfill {{PackageReference}}s scoped to targets that still need them; unused ones removed.
• Dead #if NETSTANDARD2_1 branches removed; remaining #if symbols audited (net8/net10 both define NET6_0_OR_GREATER etc.).
• dotnet build CSharpDriver.sln and full test suite green on all three TFMs.
• 4.0 upgrade/release notes document the dropped platforms and the current-Unity guidance (X.509/OIDC).
• Decision on current-Unity support confirmed with the CSHARP-5178 owner.

Related

• CSHARP-5178 — .NET/C# Driver Support for Unity (epic)
• CSHARP-5725 — C# driver stopped working with Unity since v3.2.0
• CSHARP-4971 — C# driver memory leak in Unity