-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of System.Data.SqlClient for 5.0 #30772
Comments
There was a thread a while back - one thing to consider is that if we will support this longer than we support 3.x (I assume this is the case because it will ship indefinitely) then we may need to service it after the 3.x branch and servicing infrastructure no longer exists. |
There is active work to extend the ADO api, for example https://github.com/dotnet/corefx/issues/27682 , and when that moves forward the corefx version of SqlClient should support that api if the only thing it does is ship with obsolete messages/NSE's pointing at M.D.SqlClient I'd say that it's also worth keeping for bug fixes alone. I've a couple of PR's open on it for bugs and I know there are more in there that will bite people. It's the first version of SqlClient that supports non-windows and having shipped so closely aligned to the framework it'll be in a lot of places that will presumably benefit from those bug fixes. |
For how long would we add APIs to the legacy package pointing to the new one? This sounds problematic to me. |
From https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/ :
@Wraith2 I would recommend you start submitting your bug fixes and performance improvements to Microsoft.Data.SqlClient. Even if System.Data.SqlClient stays in CoreFX, I expect we will be hesitant to take significant changes because of risk. CoreFX does not have the infrastructure to fully validate significant changes in System.Data.SqlClient as we have learned the hard way in https://github.com/dotnet/corefx/issues/40476 |
From https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/ :
Is there a chance that bug fixes will be applied to both |
The blog post has answer to this too. From https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/ :
|
My comment wasn't precise enough. The blog post talks about We are running .NET Core 2.2 on Linux in AKS backed by Azure SQL and only a week ago we managed to find a version of In our experience |
Have you tried the most recent nightly version with a fix for #30645? Does it work on AKS + Linux + Azure? The important bugs are the same type of bugs as what we are fixing in servicing releases: key scenario not working (ASK + Linux + Azure falls into this category), security issues, reliability issues (crash, hang, data loss). |
Like mars on non-windows being unstable (dotnet/corefx#38271) and command cancellation just not working (dotnet/corefx#38266) which are bug fixes have been open for 3 months, easily in time for 3.0 and yet remain unmerged. There are politics at work with SqlClient and if support/attention is reduced further i can't see even important bugs being patched. It'll be less trouble to take the honest route and just mark it as deprecated then point users at the Microsoft.Data.SqlClient |
We've spent quite a bit of time finding the current working for us version so at this stage we will wait for 4.7 to RTM with .NET Core 3.0. |
This does not qualify as important bug fix for me. We would not take this fix in servicing release either. This is the kind of fix that I expect to be made in |
It wasn't intended for a servicing release, as i said it's been sat open for 3 months which was more than enough time to get it included in the standard build before 3.0 cutoff. It's just that no-one was interested. If it's going to get even harder to make any change to SqlClient than it already is then stop pretending to support it in corefx and mark it as dead, Just tell people who find bugs to move to M.D.SqlClient and don't mess consumers around by exposing whatever disconnect is going on internally. |
@Wraith2 I have submitted dotnet/corefx#40946 to make this clear. |
There are several other packages that are shipping from 3.x branch, that are not building for .NET 5 and that may be supported "indefinitely". So this is not introducing a new problem. |
If that became a burden we could even change the build workflow to build and test a smaller part of the product. |
Fixed by #2275 |
This issue is mainly to discuss the future of System.Data.SqlClient package.
Currently it is shipped as an out of box package and public surface area of this freezed.
Do we want to keep shipping this package in 5.0.0 or should we just want to remove this from 5.0 onward ?
cc @cheenamalhotra, @Gary-Zh , @David-Engel, @safern @ericstj
The text was updated successfully, but these errors were encountered: