Announcement: System.Data.SqlClient package is now deprecated

[David-Engel]

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.

1. Update your project references: Replace references to System.Data.SqlClient with Microsoft.Data.SqlClient.
2. Modify your using statements: Update your using statements in your code files from System.Data.SqlClient to Microsoft.Data.SqlClient.
3. 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

• Frequently Asked Questions - dotnet/SqlClient Wiki - GitHub
• Introduction to Microsoft.Data.SqlClient namespace
• SQL Server and ADO.NET (Microsoft.Data.SqlClient)
• Microsoft.Data.SqlClient API Browser

[David-Engel]

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]

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]

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.

[ladeak]

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]

@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. :)

[apxltd]

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]

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]

@arknu "baloon" = 1 MB...

[David-Engel]

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.

[apxltd]

@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.

[Thorium]

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

[David-Engel]

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.

[robertmclaws]

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.

[agowa]

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?

[roji]

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

[HamsterExAstris]

@roji For Windows PowerShell (PowerShell 5), yes (i.e. no changes for .NET Framework). For PowerShell 7 (which uses the modern .NET runtime), I'm not seeing it. Am I missing something?

A member of the SqlClient team opened an issue in the PowerShell 7 repository for the migration back in May, but it doesn't seem to have any clear direction yet.

[apxltd]

Thanks @David-Engel I definitely appreciate the engagement; it's been an extraordinarily frustrating experience for us, so it's easy to feel annoyed when discussing the issue. I'm feeling a lot better after reading about things from your side and perspective.

We definitely missed that the LTS/STS support policy was publicly documented like that... despite reading release notes, etc.

I'd still strongly encourage you to reconsider the policy because it's really not intuitive from a user perspective. It's an increased cognitive burden for your consumers, who are already "overwhelmed" with the relatively fast pace of changes in the .NET ecosystem, and would never even think that "one of the .NET libraries" has a different policy.

I wouldn't want my roadmap to be tied to .NET's versions either, and I can certainly appreciate wanting to stick to SemVer... but tethering your releases to .NET is ultimately what your users will understand. Plus that's basically what all the other Microsoft. and System. libraries seem to do.

If you did that, it would make decision-making much easier for your users; "this app is still on .NET6, so we'll hold off on upgrading to 7.x then."

The "stick to even" policy works great in organizations:

• lower-level developers don't want to articulate "why upgrade" to technical decision makers
• decision-makers don't want to learn the nitty-gritty and can just keep it simple and predictable for everyone

I'm sure it would be a bit annoying for internal roadmapping, but if you released a 9.0 a few months ahead of .NET9 maybe it wouldn't be too bad.

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.

Good to know... not sure if it's helpful, but the "general feeling" over the years has been that System.Data is the older (Framework-ish) library and works (except on Linux, which is expected). Microsoft.Data is the newer (Core) library and thus should work on both.

I think it's great to see the issues being addressed, and of course risk is expected. It just didn't "feel" that risky of an upgrade from reading the release notes. We would have never upgraded without significant testing if it was released as v9 or whatever.

[David-Engel]

@apxltd

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.

Good to know... not sure if it's helpful, but the "general feeling" over the years has been that System.Data is the older (Framework-ish) library and works (except on Linux, which is expected). Microsoft.Data is the newer (Core) library and thus should work on both.

M.D.SqlClient is both.

S.D.SqlClient started as Windows only in .NET Framework. ~2015-2016, that code was forked, some incompatible features removed, and new code added (for cross-plat) to create the S.D.SqlClient package (now being deprecated) for .NET Core that was cross platform compatible. S.D.SqlClient on .NET Framework also got some new features between 2015-2019 that S.D.SqlClient on .NET Core didn't.

M.D.SqlClient took both the .NET Framework S.D.SqlClient code and the .NET Core S.D.SqlClient code and put them side-by-side into a single package that supports both .NET Framework and .NET Core. When running on .NET Framework, the code from S.D.SqlClient on .NET Framework is used. When running on .NET Core, the code from S.D.SqlClient on .NET Core is used.

Over the last 5 years or so, we've been working to merge the code bases and bring feature parity to the .NET Core side. Feature parity is largely complete, but there is still a significant subset of code that differs between the two sides. Depending on your runtime target, you could be running on one code base or the other.

[rgroenewoudt]

I would also like a SYSLIB diagnostic to warn about this in .NET

[madhon]

M.D.SqlClient is both.

S.D.SqlClient started as Windows only in .NET Framework. ~2015-2016, that code was forked, some incompatible features removed, and new code added (for cross-plat) to create the S.D.SqlClient package (now being deprecated) for .NET Core that was cross platform compatible. S.D.SqlClient on .NET Framework also got some new features between 2015-2019 that S.D.SqlClient on .NET Core didn't.

M.D.SqlClient took both the .NET Framework S.D.SqlClient code and the .NET Core S.D.SqlClient code and put them side-by-side into a single package that supports both .NET Framework and .NET Core. When running on .NET Framework, the code from S.D.SqlClient on .NET Framework is used. When running on .NET Core, the code from S.D.SqlClient on .NET Core is used.

Over the last 5 years or so, we've been working to merge the code bases and bring feature parity to the .NET Core side. Feature parity is largely complete, but there is still a significant subset of code that differs between the two sides. Depending on your runtime target, you could be running on one code base or the other.

Going forward would you recommend using Microsoft.Data.SqlClient instead of System.Data.Sqlclient on a .net 4.8 winforms desktop application (still have legacy apps to support) ? i.e., are there any enhancements./fixes that would warrant it ?

[David-Engel]

Going forward would you recommend using Microsoft.Data.SqlClient instead of System.Data.Sqlclient on a .net 4.8 winforms desktop application (still have legacy apps to support) ? i.e., are there any enhancements./fixes that would warrant it ?

Yes, I'd recommend MDS going forward. There are a lot of new features and enhancements that would warrant it. But if you don't use any of them and just need plain SQL connectivity (no Azure authentication support, no TLS 1.3), you are free to stick to SDS as long as it works for you and is supported.

In my very long-term view/opinion, TLS 1.3 is likely the main thing that will drive any remaining users away from SDS in the future. Supporting TLS 1.3 involves supporting TDS 8.0, which involved significant changes in the code. That is unlikely to ever be back ported to SDS. As with all previous versions of TLS, they are eventually rendered insecure, so when that happens to TLS 1.2 (very unknown timeframe), users who have to care about security will likely be required to move to MDS.

[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.

[fowl2]

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

[David-Engel]

@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. 🤔

[MichaelKetting]

@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!

[SimonCropp]

@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

[ErikEJ]

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

[SimonCropp]

@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

[ErikEJ]

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

[SimonCropp]

@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]

@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