Replies: 10 comments 39 replies
-
|
Compared with MySQL, PgSQL, Oracle and other driven frameworks, it is too radical |
Beta Was this translation helpful? Give feedback.
-
I think there's a misunderstanding here; .NET applications target either .NET Framework or modern .NET (Cone), rather than .NET Standard. Microsoft.Data.SqlClient still targets .NET Framework, so is usable from all .NET Framework applications.
FYI the .NET PostgreSQL driver - Npgsql - has done something much more radical, and entirely dropped support for .NET Framework in the latest version (9.0). In contrast, SqlClient still supports .NET Framework - just not via .NET Standard. |
Beta Was this translation helpful? Give feedback.
-
|
@roji I opened an issue from this, and it was closed with the statement that any critical bugs or security fixes will be fixed in the 5.x release. If this statement is true, then it's same as Oracle which I already have to handle. So will continue to use 5.x for .Net Standard and only latest frameworks will use this version going forward. |
Beta Was this translation helpful? Give feedback.
-
|
Note that I don't represent SqlClient or make any decisions, I'm just commenting here.
Which are you specifically referring to? net6.0 is out of support, as well as Xamarin if I'm not mistaken.
I'm still trying to understand the problem with simply... multitargeting. A lot of the feedback in this thread seems to be a result of the fact that a change was made, rather than the actual impact it has... I definitely wouldn't want to see people staying on 5.x only because they need to make a change to their |
Beta Was this translation helpful? Give feedback.
-
Again, I'm not part of SqlClient, but I'm not sure this statement implies that SqlClient 5.x will be supported forever. According to this, 5.2 will go out of support in August. /cc @paulmedynski |
Beta Was this translation helpful? Give feedback.
-
|
The SqlClient support lifecycle page is accurate. The v5 family of releases will continue to target .NET Standard, so folks can keep using those if they need .NET Standard. I've provided a copy of my comment from @joshdean2000 's issue below for reference. |
Beta Was this translation helpful? Give feedback.
-
This is an interesting discussion, but wanted to flag that, because the view here is that "netstandard2.0 is no longer supported," Dependabot missed a critical security update for Microsoft.Data.SqlClient 5.2.2. It is fine if the team chooses the unofficial stance that "netstandard2.0 is EOL" (prima facie), but what is the plan to ship security updates to repackage Microsoft.Data.SqlClient when transitive dependencies become vulnerability? I think not emitting a warning prior to making this decision was a mistake. Recommend simple amelioration by:
I think, if you had just done step 1, there would be way less talking about this issue than there is on here. Giving people an EOL heads up that is more than a couple of months would allow development teams to think through resourcing constraints and communicate up and down the corporate hierarchy on resource strategy. For me, I think this just means:
|
Beta Was this translation helpful? Give feedback.
-
|
CentOS7 (GLIBC) is not supported since .NET8, so .NET7 is still used |
Beta Was this translation helpful? Give feedback.
-
|
Posting here as well: 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. |
Beta Was this translation helpful? Give feedback.
-
|
@jeme |
Beta Was this translation helpful? Give feedback.
-
|
From issue #3139 they have stated the following
So the work around I have for this for now. <ItemGroup Condition=" '$(TargetFramework)' != 'netstandard2.0' AND '$(TargetFramework)' != 'netstandard2.1'">
<PackageReference Include="Microsoft.Data.SqlClient" Version="6.0.1" />
<PackageReference Include="Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider" Version="6.0.0" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' OR '$(TargetFramework)' == 'netstandard2.1'">
<PackageReference Include="Microsoft.Data.SqlClient" Version="5.2.2" />
<PackageReference Include="Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider" Version="5.1.0" />
</ItemGroup>Hopefully this will help others targeting .Net Standard. |
Beta Was this translation helpful? Give feedback.
-
|
This deprecation + drop of .NET Standard support was a nasty combo to wake up to.
|
Beta Was this translation helpful? Give feedback.
-
|
There should have been some kind of impact assessment done before this was done. It would have clearly shown this was a bad idea. |
Beta Was this translation helpful? Give feedback.
-
|
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. The community has had a year to collaborate and voice concerns related to this change. 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.1 and 5.2 releases, which are currently receiving security fixes, critical bug fixes, and backports of select functionality. The support lifecycle is maintained here: https://learn.microsoft.com/en-us/sql/connect/ado-net/sqlclient-driver-support-lifecycle |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate posting the discussion above. My original issue was not so much the decision to drop .Net Standard for the Microsoft.Data.SqlClient 6.x release, it is the timing of how things occurred. System.Data.SqlClient gets deprecated, we migrate our Standard Projects to Microsoft.Data.SqlClient 5.x, only to find out it is SqlClient and the kitchen sink (30+ transitive dependencies and 10 languages), then 6.0 gets updated with no .NetStandard support. I do appreciate however the mention that 5.1 and 5.2 still have support. I hesitate to use multi-targeting because .net Standard fixed that with no added complexity in my code. I do look forward to the possibility of a leaner SqlClient in the future, and thanks again for what you all do. |
Beta Was this translation helpful? Give feedback.
-
Please outline in detail what steps were taken to engage with the community, receive feedback and for all developers using this in .NET Standard projects to voice their concerns about this change, aside from the ability to stumble upon a discussion in this repo that >95% of people this affects wouldn't find unless they go looking for it. What absolute Pelican decided that this would be a good idea instead of maybe first moving the Azure shit and all the other bloat that comes with installing the Microsoft.Data.SqlClient package to separate ones before dropping support for things people have in production? |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to understand the level of frustration here. Maybe I'm missing something. .NET Standard was created to bridge all the various .NET implementations (Framework, Core, Mono, Xamarin, etc.). But the majority of those implementations have been rendered obsolete starting with .NET 5 in 2020. Now that those implementations have largely dropped out of support, There's just .NET and .NET Framework. So, for modern applications and libraries supporting runtimes that are not EOL, there are only two targets an application might run on. It stands to reason that libraries would support and test those targets moving forward, too. Now, when you create a .NET Standard library that depends on MDS 6.0.0, yes, you get a build warning:
And we all hate warnings. But what's the end result? Ignore the warning for a moment. Create an application that depends on your .NET Standard library. What does that application target? If the developer cares at all about security, it's targeting a runtime that's not EOL - .NET 8, 9, or .NET Framework. Build it. No warning. It works. I see two simple solutions to the warning in the .NET Standard library:
What am I missing? |
Beta Was this translation helpful? Give feedback.
-
That's assuming you have no one but yourself calling your code. |
Beta Was this translation helpful? Give feedback.
-
|
It's very clear here if you are targeting .Net Framework and .Net then target .Net Standard 2.0. No where does it say Target .Net 4.6.2. It's also clear that .NET Standard is not deprecated. |
Beta Was this translation helpful? Give feedback.
-
|
@fbenoit-coexya, I could not agree with you more. When we started moving away from Framework and migrating some of our apps to Core and .Net, we opted for Standard. It probably would have been better if we had opted for strictly multi-target (.Net and FW). @joshdean2000, it is ironic that right before they state ".NET Standard not deprecated," they have the section ".NET Standard problems," which gives me the sense of why Standard is slowly dying. I mean, the API has not been touched in more than seven years. I wish Microsoft would update the Standard page and recommend starting to move on. Even the page that Support multiple .NET Framework versions in your project file, states "We recommend that you create a .NET Standard class library for best compatibility." On a side note, it would be awesome if the .Net Framework also supported modern syntax instead of being stuck in 7.3. This would make multi-target projects easier to code without having to add directives all over the place. Now that's not for this group :-) |
Beta Was this translation helpful? Give feedback.
-
It is possible to target .NET Framework with the latest syntax. In our projects we target .NET Framework using the latest C# compiler (version 13) by using the latest .NET SDK (9.0.200 as of February 2025) to run the build. There are some C# features that are not supported because of runtime requirements, but most work as expected (and you can expand compatibility by adding |
Beta Was this translation helpful? Give feedback.
-
|
I think, ergonomically, netstandard2.0 is conceptually much lighter weight than a package that purports to target "net48;net8.0;net9.0" - it tells me there likely is no fancy memory tricks (which can be a significant minus), but it also tells me that the package is so simple that it should be easy to interop with other packages. The main drawback to netstandard2.0 is in that, the default nuget package resolution policy is conservative, and that tends to prevent security fixes from being taken in ASAP. Just my two cents. I do think, from a planning perspective, if the plan was "when net core 3.1 goes eol, netstandard2.0 is eol", then that could have been communicated via a MSBuild warning when using the package. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any way to get this Issue 2340 updated? The very first line in it is factually incorrect and causing problems. ".NET Standard is EOL" So now when clients are getting the error building any .Net Standard libs they are getting the warning about SqlClient. They research and upon finding this are to put it very politely concerned that they need to convert all libs, etc. due to this statement. |
Beta Was this translation helpful? Give feedback.
-
|
@joshdean2000 @jeme if you're interested in having a general discussion on .NET Standard and what EOL means, I suggest doing that in another repo as the SqlClient repo isn't the right place for that. Beyond that, regardless of the status of .NET Standard or what EOL means, a library like SqlClient can choose to support .NET Standard 2.0 or to not support it. For example, neither EF Core nor ASP.NET support .NET Standard 2.0 in recent versions (or even .NET Framework for that matter). A library is free to support the TFMs that it wants to support. Beyond that, for whether SqlClient should support .NET Standard and the effect on the ecosystem, I think this has already been discussed extensively in the other comments and issues and nothing new is being said here. |
Beta Was this translation helpful? Give feedback.
-
|
@roji ASP.Net and EF Core are not multi-targeting so not comparable. So, another reason why this decision seems to be made for invalid reasons. My problem with EOL is this is given as the reason for this change. No where else is this declared. So, this is the only one impacted by this change. |
Beta Was this translation helpful? Give feedback.
-
Implementation
Reference-only This is certainly less work than an implementation. There is still work to be done to figure out how to generate an appropriate reference DLL that can be used. Let's even assume there are tools to do this without manual work to build a scaffold .cs file and it turns out to be not too much work. Now let's say we have a DLL that can be included in the NuGet package. On NuGet.org, it will appear that .NET Standard is a compatible framework for SqlClient. What's the expectation from a typical user that compatible frameworks are actually supported? Yes, we can document official "support" elsewhere and redirect them when they ask why SqlClient doesn't work against Xamarin, but that's a bit of a muddled user experience. I'm not completely opposed to this approach, but something about it doesn't feel quite right... |
Beta Was this translation helpful? Give feedback.
-
|
In my mind, you should not need to defend why targeting modern runtimes is beneficial. I think the real goal with some of this feedback is to improve engineering guidance on a going forward basis to avoid repeat mistakes. Thanks for all your contributions to SqlClient, David! |
Beta Was this translation helpful? Give feedback.
-
To be fair though, you had all this in there before the removal, or was there substantial changes from 5.X to 6.X on this part? If that is the case then I guess fair point.
Maybe it did not come through clear enough, but this is not needed at all in my point of view. Since you only wish to test supported runtimes, which makes perfectly sense, then it doesn't make any sense to run tests on the standard output at all IMO, your running tests for a case that would never exist unless someone really jumped some hoops in the same way you describe you have to do with the tests to force switch in the .NET Standard DLL. If anything should be tested in this scenario, it would be targets that would actually end up using the .NET Standard Implementation, which means you would perhaps run tests under e.g. .NET 6.0 being the most recent .NET LTS that is out of support and which would end up using the .NET Standard output. But that is a choice to test under a runtime you actually choose not to support, so again, perfectly fair to not do that at all. Is all this due to confusion about what happens in the case of: SQLClient (5.x) targets
SomePackage dependent SQLClient:
EndApplication dependent on SomePackage:
So... Dependency tree: EndApplication -> SomePackage -> SQLClient What does people think you end up with in the output?: A)
B)
? - The correct answer is B. Now I haven't made exhaustive testing on this, so can't say there isn't some wierd situation where you could end up with sqlclient_std20.dll instead, feel free to share if anyone knows of such cases.
I can agree that it could be an annoying aproach if your on an out of support runtime, while there is NotSupportedException or PlatformNotSupportedException which to some degree would give a fairly clear message, they are also not a 100% fit, so the message should be very clear. So I think it's fair if this require some careful consideration. If generated blindly, it might be just as bad a solution as people just accepting the warning that the package was restored as .NET 461 BTW. We would risk creating a .NET Standard package that uses that, however that doesn't exist in the .NET 8 version of the package, which causes a crash for people using the intermediate package on .NET 8. Generating a reference assembly for .NET Standard can weed out SomeNetFrameworkSpecificFeature so it was not part of the .NET Standard interface. As such we would not risk using it. Now this should ofc. be discoverable given you have the right tests in place, so ideally this would only be an annoyance hitting the auther behind the intermediate package. A final option is ofc as already outlined, that we stick with the 5.x version. Two annoyance I have with that: A) We can actually update the package to 6.x and it will just give that somewhat silent warning about having restored it as .NET 461, in this scenario I would really actually have liked a more "Up front in my face" warning, but that would be for the Nuget and/or VisualStudio team to handle I guess. Because my biggest grudge on all this is actually that I got so far down the line before I discovered this. Luckely reverting to 5.X wasn't that difficult, but I fear that was situational. B) When looking at:
It would have been really nice to see either the 5.2 being an LTS, and therefor being supported for longer OR a 5.3 release as a LTS version, specifically to provide the last 5.X version as LTS, the fact that it's not the latest 5.X that is LTS is... just odd... IMO. And then getting a bit longer support for that LTS would be appeasing as well. With all the hard choices that goes with not having true support for SqlClient on .NETStandard 2.0, I would maybe be inclined to prefer the last option here, especilly if something could be done about my two annoyances with it. Not that there isn't downsides on that as well, but i might be more accepting of those for the time being at least. |
Beta Was this translation helpful? Give feedback.
-
|
Because i created a lot off extensions for multiple projects the choice for using .net standard 2.0 was easy. Build once and use it in all projects that do classic .Net or all new ones. In my opinion it should still support .Net Standard regardless of EOL comming or not. Then it could drop support for .Net 4.6.1. But offcourse can create a sdk project that uses multiple targets.. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions