Microsoft.Data.SqlClient 6.0 and .Net Standard

[joshdean2000]

Discussed in #3115

^{Originally posted by felovala January 15, 2025}
I'm puzzled by the decision to drop support for .NET Standard in the 6.0 release. This change leaves anyone with a .NET application using .NET Standard in a bind. They are now forced to choose between the deprecated System.Data.SqlClient 4.9.0 or Microsoft.Data.SqlClient 5.2, which can't be upgraded or patched due to the lack of support for .NET Standard beyond that version. It's hard to believe that, despite .NET Framework and .NET Core being maintained concurrently, the connection between the two is gradually fading away.

This is causing problems with any package developed using this but targeting .Net Standard. Now when building it generating warnings about and displaying there are issues with the reference.

This doesn't follow Microsoft recommendations, or other Microsoft libraries such as Azure SDK, Dependency Injection, etc.

You have effectively decided that anyone who using this package now has to go change from .Net Standard and make the packages target specific versions of .Net and .Net Framework.

All you need to do is look at the Used By list in NuGet.org to see those impacted by this change. This includes "Microsoft.Extensions.Caching.SqlServer".

[twsouthwick]

I understand from previous issues that a large driver of the change was difficulty in maintaining the .NET Standard implementation. Could there be a reference assembly that could allow compile time support for .NET Standard?

[jeme]

Just hit this as well, considering that .NET 4.6.2 implements netstandard2.0 and how old 4.6.2 is compared, what is making it more difficult to target netstandard2.0 instead of .NET 4.6.2?

(I understand that 4.6.2 can have features not being parts of the standard, so that was a genuine question, not a witty remark)

.netstanard2.0 (or below) is generally still very usefull when developing frameworks/packages for both platforms. (Sadly not everyone has moved on). Multi target builds are still annoying, especially if it hits on a low trancient dependency, then it has a nasty ripple effect.

[bweberde]

Netstandard2,0 is still the only way we can have a single library that supports both .net core and framework. If the support for netstandard2.0 is dropped that means that all sqlclient dependent code in these libraries has to be duplicated which is very annoying.

[paulmedynski]

Here's the original issue and discussion started a year ago: #2340

Subsequent PR is here: #2386

Both of those include good discussion of the pros/cons of dropping .NET Standard as a target. Ultimately, we decided that multi-targeting .NET Framework 4.6.2 and .NET 8.0 provide the best balance between breadth of support and access to modern APIs and features.

We realize that changes like this will always have casualties, and we don't make these decisions on a whim. The .NET ecosystem continues to evolve, and we must set ourselves up move forward with it.

If you still need target support for .NET Standard, it will remain in the MDS 5.x releases, which are currently receiving security fixes, critical bug fixes, and backports of valuable functionality.