Repository navigation
Announcement: System.Data.SqlClient package is now deprecated #2778
Description
Announcement: System.Data.SqlClient package is now deprecated
We announced Microsoft.Data.SqlClient in the first half of 2019 and shipped the first stable package later that year. That release coincided with .NET Core 3.0. We’ve been developing Microsoft.Data.SqlClient in the dotnet/SqlClient repo since that time, over the last five years. It’s now time to start the deprecation process for the System.Data.SqlClient package. We plan to take a staged process to deprecation, with the intent to align support changes and associated code transition activities between these libraries to natural migration points between .NET major versions.
All System.Data.SqlClient users are encouraged to transition to Microsoft.Data.SqlClient. We offer improvements and significantly higher support via the Microsoft.Data.SqlClient package.
Plan
We intend to deprecate the System.Data.SqlClient package in stages.
- Before .NET 9 GA:
- Publish a new 5.0.0 package, including the following changes.
- Remove support for .NET 7 and earlier and .NET Framework 4.6.1 and earlier.
- Publish assets for the following target frameworks: .NET 8, .NET Framework 4.6.2, .NET Standard 2.0.
- Add Obsolete attributes to .NET 8 and .NET Standard 2.0 assets. This will generate new warnings for .NET 8+ and .NET Standard users.
- Continue to offer security servicing, for .NET 8, and .NET Framework 4.6.2+ application users.
- After .NET 9 GA:
- No change
- We will not support this package for .NET 9+ application users.
- After .NET 8 EOL:
- Remove support for .NET 8 users (the .NET 8 library will be removed).
- Maintain support for .NET Framework 4.6.2+ users.
- Security servicing will be provided via .NET Framework, not the package, at that point.
- We do not expect to update the package again after this point.
- We will not mark the package as deprecated since it will only support .NET Framework users with an implementation provided by .NET Framework.
We will remove support in the package for unsupported .NET and .NET Framework versions at various stages of this deprecation plan. Users affected by those changes are encouraged to move to a supported .NET or .NET Framework version and to adopt the Microsoft.Data.SqlClient package.
We decided to remove support for .NET 6 since it will go EOL shortly after this new package is released, even though .NET 6 will still be supported at the time. Publishing a .NET 8 library significantly simplifies the plan, both in terms of what we will deliver and what we need to explain.
For .NET dates, see .NET Releases. .NET 9 will GA in November of this year. .NET 8 will go EOL in November, 2026.
The current package version of System.Data.SqlClient is 4.8.6, at the time of writing. These changes will be made with a 5.0.0 version and later.
Note: This deprecation doesn’t apply to the System.Data.SqlClient namespace in .NET Framework.
Microsoft.Data.SqlClient
Daily downloads of Microsoft.Data.SqlClient on nuget.org are nearing 50% higher than System.Data.SqlClient. We expect the gap in usage between the two libraries will continue to increase. Microsoft.Data.SqlClient is the best library we offer to access SQL Server.
We are committed to providing high-quality, performance-driven, and secure data access technologies. We strongly encourage users to transition to Microsoft.Data.SqlClient. It is actively maintained and supports the latest SQL Server features.
How to migrate?
Add the NuGet package to your project, then update your references and using statements. Our porting cheat sheet provides a step-by-step set of changes you may need to make.
- Update your project references: Replace references to System.Data.SqlClient with Microsoft.Data.SqlClient.
- Modify your using statements: Update your using statements in your code files from System.Data.SqlClient to Microsoft.Data.SqlClient.
- Test your application: Thoroughly test your application to ensure that it works as expected after the migration.
We also plan to support semi-automatic migration via .NET Upgrade Assistant.
Support & Feedback: If you have any questions or need assistance with the migration, please reach out through our official support channels or join the discussion on our GitHub repository.
Resources
Activity
David-Engel commentedon Aug 15, 2024
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.)
ErikEJ commentedon Aug 16, 2024
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)
lwinch2006 commentedon Aug 16, 2024
Is this (from article) still valid or not?
ladeak commentedon Aug 16, 2024
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.
SeanKilleen commentedon Aug 16, 2024
@lwinch2006
The article is from 2019, as this post mentions. I think by waiting half a decade they covered the "anytime soon" promise. :)
apxltd commentedon Aug 16, 2024
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.
arknu commentedon Aug 16, 2024
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.
ErikEJ commentedon Aug 16, 2024
@arknu "baloon" = 1 MB...
David-Engel commentedon Aug 16, 2024
@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.
@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.
@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.
[-]Announcement: System.Data.SqlClient is now deprecated[/-][+]Announcement: System.Data.SqlClient package is now deprecated[/+]apxltd commentedon Aug 16, 2024
@David-Engel thanks for the reply, and I hope you don't mind more constructive feedback.
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.
Thorium commentedon Aug 16, 2024
Both drivers have their own issues. I'd prefer users to pick their poison.
David-Engel commentedon Aug 16, 2024
@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
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.
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.
15 remaining items
SimonCropp commentedon Aug 28, 2024
@David-Engel
I just tested some System.Data.SqlClient on net9 and it seems to work fine
ErikEJ commentedon Aug 28, 2024
@SimonCropp Why should it not - unless there are corner runtime breaking changes?
SimonCropp commentedon Aug 28, 2024
@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.
SimonCropp commentedon Aug 28, 2024
@David-Engel
The Azure related (multiple) CVEs definitely broke builds for us.
It also broke our deployments when using
-windowsand the azure package forced a requirement onMicrosoft.WindowsDesktop.Appand all our apps failed at startup. dotnet/sdk#37892aguzev commentedon Mar 12, 2025
Besides the size, unused dependencies pull us towards dependency hell.
Classicrichblog commentedon Apr 4, 2025
Approve to get my assets views
tscilipoti commentedon Sep 8, 2025
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.
David-Engel commentedon Sep 29, 2025
@tscilipoti
Please file an issue with a reproduction of what you are experiencing. Microsoft.Data.SqlClient fully supports .NET Framework applications.