Note: Posting here in SqlClient first to gauge the community response before a broader announcement in .NET. Feedback is welcome. We know there are MDS issues that hold some users back from migrating from SDS that we are trying to address. (Like the Azure dependencies. EDMX designer issue, and Linux/managed SNI issues.)

Perhaps mention that I and the EF team recently published this package: https://www.nuget.org/packages/Microsoft.EntityFramework.SqlServer (for EF 6 Classic users on .NET and .NET Framework)

Is this (from article) still valid or not?

What does this mean for System.Data.SqlClient?
It means the development focus has changed.
We have no intention of dropping support for System.Data.SqlClient any time soon.
It will remain as-is and we will fix important bugs and security issues as they arise.
If you have a typical application that doesn’t use any of the newest SQL features,
then you will still be well served by a stable and reliable System.Data.SqlClient for many years.

I think it is a bit too early to deprecate SqlClient. There was little first-party support for migration with the old EF projects. Now it is there, but it has been just recently added.

@lwinch2006

Is this (from article) still valid or not?

What does this mean for System.Data.SqlClient?
It means the development focus has changed. 
We have no intention of dropping support for System.Data.SqlClient any time soon. 
It will remain as-is and we will fix important bugs and security issues as they arise. 
If you have a typical application that doesn’t use any of the newest SQL features, 
then you will still be well served by a stable and reliable System.Data.SqlClient for many years.

The article is from 2019, as this post mentions. I think by waiting half a decade they covered the "anytime soon" promise. :)

If you "are committed to providing high-quality, performance-driven, and secure data access technologies", you should support System.Data until Microsoft.Data and the team is ready for prime time.

It not close, and the NET8 library is still effectively unusable on Linux for SQL Server. This has been an issue since May, and it's been like pulling teeth to get the team to address it. The library was clearly never tested under any moderate load (few dozen connections?) on Linux.

This was a major regression that caused a lot of pain for anyone who used the library on Linux.

There is apparently also a big rewrite of connection pooling underway, and the chance of that working out the gate is effectively zero. Especially given the current testing discipline.

Are you going to get rid of the useless Azure dependencies, then? Because "upgrading" to Microsoft.Data.SqlClient will balloon your application size to bring in a bunch of Azure dependencies that are only relevant for the small percentage connecting to Azure SQL.

@arknu "baloon" = 1 MB...

I think it is a bit too early to deprecate SqlClient. There was little first-party support for migration with the old EF projects. Now it is there, but it has been just recently added.

@ladeak
It looks like we lost some clarity between System.Data.SqlClient in .NET Framework and the System.Data.SqlClient NuGet package while drafting the announcement. The System.Data.SqlClient namespace in .NET Framework isn't being deprecated as part of this. We'll try and add some wording to differentiate that.

If you "are committed to providing high-quality, performance-driven, and secure data access technologies", you should support System.Data until Microsoft.Data and the team is ready for prime time.

It not close, and the NET8 library is still effectively unusable on Linux for SQL Server. This has been an issue since May, and it's been like pulling teeth to get the team to address it. The library was clearly never tested under any moderate load (few dozen connections?) on Linux.

This was a major regression that caused a lot of pain for anyone who used the library on Linux.

There is apparently also a big rewrite of connection pooling underway, and the chance of that working out the gate is effectively zero. Especially given the current testing discipline.

@apxltd
The issue you mentioned only exists in the 5.2 (non-LTS) line (not the 5.1 LTS line) and should be addressed via PR #2779 yesterday. A 5.2.2 hotfix is coming soon. I agree that we need improved stress testing to avoid regressions like this. It's on our TODO list.

The connection pooling rewrite is part of a bigger project to address perf problems with async and MARS on non-Windows. Significant engineering resources have been added to work on it. The plan is for the rewrite to be available under a switch so that it can be battle tested without regressing current code. Only after it's proven out by real-world usage will the new code replace the old.

Are you going to get rid of the useless Azure dependencies, then? Because "upgrading" to Microsoft.Data.SqlClient will balloon your application size to bring in a bunch of Azure dependencies that are only relevant for the small percentage connecting to Azure SQL.

@arknu
This is very visible on our radar and something I hope we can address. As @ErikEJ alluded, the severity of the issue greatly varies from user to user depending in their perspective. Nothing is "broken", so those who don't understand your perspective need to be convinced to spend effort addressing it. It becomes a particularly tricky discussion when you are proposing breaking customers to address it. Also, the percentage of Azure SQL customers is probably not as small as you think.

@David-Engel thanks for the reply, and I hope you don't mind more constructive feedback.

The issue you mentioned only exists in the 5.2 (non-LTS) line (not the 5.1 LTS line)

I think your point there furthers my point on the team not quite "ready for prime time" -- this is the first time I've heard of the LTS / non-LTS distinction for the library, and I have never seen this communicated in any meaningful manner outside of your team. I'm sure there's some internal memo in the repository here, but unless you clearly communicate this then it means nothing.

That said, I can't imagine how you could effectively communicate this distinction. This is basically is driver, published by Microsoft, for a Microsoft product, and this means users will just expect it to work. Perhaps if you tied it to the .NET versions, which "everyone" understands to be LTS/STS, then you'll have a much better chance of communicating this?

Otherwise, please rethink your policy altogether. There's no benefit to your team having a "secret" LTS/non-LTS distinction, because you're just going to make non-LTS releases lower-quality. And as I mentioned, everyone expects it to "just work".

I'm glad that you were able to fix this issue, but we're 5+ months since first report, for something that was absolutely trivial to reproduce. I know you will learn form this, but this was a major business disruption that lead to a major loss of confidence in not just this library, but SQL Server as a whole.

System.Data.SqlClient "just works" and has not had any major issues like this in the 20ish years it's been around. I know it has other problems, but we've never seen anything like this.

Both drivers have their own issues. I'd prefer users to pick their poison.

I think your point there furthers my point on the team not quite "ready for prime time" -- this is the first time I've heard of the LTS / non-LTS distinction for the library, and I have never seen this communicated in any meaningful manner outside of your team. I'm sure there's some internal memo in the repository here, but unless you clearly communicate this then it means nothing.

@apxltd
It's been publicly documented in multiple places since 2019:
https://github.com/dotnet/SqlClient/blob/main/SUPPORT.md
https://learn.microsoft.com/en-us/sql/connect/ado-net/sqlclient-driver-support-lifecycle?view=sql-server-ver16#microsoftdatasqlclient-release-cadence

That said, I can't imagine how you could effectively communicate this distinction. This is basically is driver, published by Microsoft, for a Microsoft product, and this means users will just expect it to work. Perhaps if you tied it to the .NET versions, which "everyone" understands to be LTS/STS, then you'll have a much better chance of communicating this?

But you do have a point. Not everyone reads the docs and we haven't called it out on the release announcements. I'll be sure to add the support distinction to future release announcements. I'm not excusing the Linux regression. Even non-LTS releases shouldn't have the regression we saw. I was just pointing out that there was a simple, supported fallback to the LTS release for the issue. We'd prefer not to be tied to .NET versions, though.

System.Data.SqlClient "just works" and has not had any major issues like this in the 20ish years it's been around. I know it has other problems, but we've never seen anything like this.

I want to differentiate System.Data.SqlClient on .NET Framework on Windows (20+ year old code base) with System.Data.SqlClient on Linux. There is a significant amount of code behind the Linux version that is less than 10 years old and doesn't run on Windows, by default. System.Data.SqlClient on Linux has some of the same underlying perf issues around async and MARS that Microsoft.Data.SqlClient has (inherited). We are trying to address these issues and change always comes with inherent risk. You can't have forward progress with zero risk. Yes, we try to minimize it, as much as possible, but it will always be there. While System.Data.SqlClient "just works", it isn't seeing any changes or enhancements to make it better. Again, not excusing the issues. We can and should do better. Just pointing out the current situation.

If it’s being deprecated then the EF6 designer should be made fully compatible with MDS and officially supported in that configuration, using SDK-style projects.

System.Data.SqlClient is one of the simplest and most flexible implementations to work with MSSQL from PowerShell, what's the replacement for that use case going to be?

@agowa that's very clearly called out in the above announcement.

Removing support for NET 9 is very agressive, given that its' release is imminent. Blocking people from runtime updates on short notice is not cool.

(also it'd be really cool to link directly to this page from the announcement, rather than making us fish through issues)

@fowl2

Removing support for NET 9 is very agressive, given that its' release is imminent. Blocking people from runtime updates on short notice is not cool.

There is no removal of .NET 9 support. .NET 9 was never supported by System.Data.SqlClient.

(also it'd be really cool to link directly to this page from the announcement, rather than making us fish through issues)

It's linked right at the top of the announcement. 🤔

@David-Engel As stated by @edwardneal in the linked ticket #1108 , it is mandatory we desperately need the Azure-et-al-free version of Microsoft.Data.SqlClient before we are able to migrate. For the time being, I solve this by sticking to System.Data.SqlClient. Please prioritize this dependency cleanup. Thank you!

@ErikEJ

"baloon" = 1 MB...

I am confused by the "1MB"? For me a published empty console app with symbols included is:

• With Microsoft.Data.SqlClient 18.5MB
• With System.Data.SqlClient 6.9MB

@SimonCropp I think I looked in the bin folder, not a publish - my bad

@David-Engel

There is no removal of .NET 9 support. .NET 9 was never supported by System.Data.SqlClient.

I just tested some System.Data.SqlClient on net9 and it seems to work fine

@SimonCropp Why should it not - unless there are corner runtime breaking changes?

@ErikEJ i think in the announcement there needs to be a bit more clarity over what "supported" means.

in the context of "what runtimes a nuget is supports" then System.Data.SqlClient supports net9.

in the context of "what runtime the sqlclient team will provide support for System.Data.SqlClient" then System.Data.SqlClient does not supports net9.

@David-Engel

(Azure dependencies)... Nothing is "broken", so those who don't understand your perspective need to be convinced to spend effort addressing it.

The Azure related (multiple) CVEs definitely broke builds for us.

It also broke our deployments when using -windows and the azure package forced a requirement on Microsoft.WindowsDesktop.App and all our apps failed at startup. dotnet/sdk#37892

@arknu "baloon" = 1 MB...

Besides the size, unused dependencies pull us towards dependency hell.

Approve to get my assets views

Announcement: System.Data.SqlClient package is now deprecated

I would love to see a clear declaration on this page - and on the cheat sheet for porting - that Microsoft.Data.SqlClient does not properly support .NET Framework applications. I spent a loooong time trying to make it work and ultimately gave up. The whole thing with the unmanaged .SNI files was intractable. Among many other issues, NuGet would not allow the installation of a package that depended on Microsoft.Data.SqlClient because of the transitive dependency on those files.

Announcement: System.Data.SqlClient package is now deprecated

I would love to see a clear declaration on this page - and on the cheat sheet for porting - that Microsoft.Data.SqlClient does not properly support .NET Framework applications. I spent a loooong time trying to make it work and ultimately gave up. The whole thing with the unmanaged .SNI files was intractable. Among many other issues, NuGet would not allow the installation of a package that depended on Microsoft.Data.SqlClient because of the transitive dependency on those files.

@tscilipoti
Please file an issue with a reproduction of what you are experiencing. Microsoft.Data.SqlClient fully supports .NET Framework applications.

I just wanted to express my thanks for adding another bullet point for the migration hell that is Framework to modern .NET. Anyone trying to incrementally port things over is better off burning it to the ground and rewriting it.