Repository navigation
Drop support for .NET Standard #2340
Description
Active discussion related to this change is here: #3115
- .NET Standard is EOL
- Carries a different tree of dependencies, making dependency management more complex
- Simplifies build, test and packaging (smaller matrix)
- Gets rid of special case code for .NET Standard
- Increases the ability to merge .NET and .NET Framework classes
Wonder if any platforms will suffer from this?
Activity
David-Engel commentedon Feb 5, 2024
I agree, it would be nice to do this. I'm also trying to think about if/what we might impact if we do this. If anyone has comments for or against, please add them here.
NotTsunami commentedon Feb 15, 2024
This combined with potentially splitting out the Azure dependency could be fantastic for the next major release.
ErikEJ commentedon Feb 15, 2024
@NotTsunami make sure to add a thumbs up to each of the related issues. Why is this important?
NotTsunami commentedon Feb 15, 2024
Gave a hearty thumbs up. I don't view it as important or required, but the biggest thing is for maintenance going forward. Fewer dependencies and code paths to worry about is great for both upstream and downstream projects.
I'm not as familiar with the audience of this package outside of EF Core, so I'm not sure how this will affect those. In theory, they would be able to stick with 5.x and hopefully be fine. The only use-case I can think of for .NET Standard still is Unity. I doubt many Unity users are using this package directly and not a web service/API, but Unity defaults to .NET Standard 2.1, last I recall.
ErikEJ commentedon Mar 4, 2024
@David-Engel @JRahnama I have a PR ready, but I assume the CI pipeline must be updated first (to skip .NET Standard)
Is that anything I can assist with?
JRahnama commentedon Mar 4, 2024
@ErikEJ, I would suggest pushing the PR. This will enable us to review it first and adjust the pipelines accordingly. Of course, we may expect it to fail initially.
twsouthwick commentedon Mar 18, 2024
Where is it documented that .NET Standard 2.0 is EOL? This is an important target for folks who are migrating from .NET Framework to .NET Core. We often tell them to get their projects on .NET Standard 2.0 (2.1 is a worthless target in this scenario) and then they can be ready to move on. Multitargeting is a possibility, but has proven to be a more difficult one in practice for many customers with large code bases.
Please see:
David-Engel commentedon Mar 19, 2024
@twsouthwick
https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/
.NET Standard isn't EOL. It's just not needed for SqlClient anymore. Your links actually describe exactly why we can drop .NET Standard. SqlClient already multitargets to support everything we need. Currently we target .NET Framework, .NET 6, and .NET Standard.
We already have a .NET Framework target for .NET Framework support. No need for .NET Standard for that.
Xamarin and .NET Core 3.x are essentially EOL'd by .NET 5+. Mono is not getting future investments (it's in the same position as .NET Framework).
Eliminating the .NET Standard target from SqlClient eliminates a lot of complexity and maintenance costs. The .NET Standard API wasn't sufficient for all SqlClient needs, so we were never going to be able to eliminate either of the other two targets. With .NET 5 unifying things, it just doesn't make sense to keep our .NET Standard target around.
6 remaining items
jeme commentedon Feb 5, 2025
This clearly sounds like the only thing on your mind is "At the top of the stack" developers, if what your develpoping is a Application, be that ASP.NET, MAUI or other, then your right, this isn't much of an issue.
Yes you can technically target it as .NET 461 from Net Standard, but it's not something that makes one sleep sound at night.
This change hits all those in between and it has really nasty ripples. Imagine a dependency tree like:
SqlClient by Microsoft <- STD2.0 Library By Brian <- STD2.0 Library By Julie <- STD2.0 Library By Eric <- NET 481 Application By Isabel.
This change hurts Brian, Julie and Eric.
Isabel is largely or completely unaffected because as you say, it will be the .NET Framework 461 dll that is used at the end here anyways. (This is actually not clear to all, we recently had a discussion on the Lucenenet project about that and it clearly suprised some how this worked)
The only one who benefits from all of this is Microsoft (well that is ofc dependent on how the community takes this, if it causes more to abandon SQL Server then you could argue that only does not actually benefit Microsoft after all)
A reference DLL similar to those in the core part's of the .NET framework (I guess thats what the netstandard package delivers) would be a more than acceptable solution IMO.
Why is this more difficult to test than the current multi targeting? It should not be needed to test it on .NET 8+ or .NET 461+ as there are actual implementation specific for those, meaning this should just be a .NET 5/6/7 target, and you could argue that if there is no official support for that, then it should not be tested at all leaving the tests in the exact state they are now.
Now here a simple reference DLL may be a better option because it could generate noise in the issue track if people on .NET 5/6/7 was to begin an use this, techincally most of the things would probably work, but if they do hit a defect that is due to being on an older platform, they would perhaps create a bug report just to be turned down with "not officially supported".
So here a "empty reference dll" might be better would simply just not work.
billybooth commentedon Feb 10, 2025
This one hurts us as well. We are in the same boat as Brian, Julie, and Eric in the beautifully expressed comment above (thank you @jeme), because we maintain a .NET Standard 2.0 library and are now unable to update
SqlClient; this change is probably going to force us to reorganize everything and multitarget.henkkelder commentedon Mar 17, 2025
This really hurts me also.
We have a very large ORM like library we need from both .NET 4.8.1 as from .NET 8. I only just migrated from System.Data.SqlClient to the Microsoft version and just upgraded to 6.0.1. I see a lot of warnings now.
mason-mcglothlin commentedon Mar 24, 2025
We just ran into this as well. We have a large ASP.NET Web Forms/MVC 5 project we're in the process of gradually migrating to ASP.NET Core, using YARP to proxy requests to the older app. Both our old and new apps refer to .NET Standard class libraries that need Microsoft.Data.SqlClient, but when we upgraded to v6, we started getting compiler warnings that forced us down to v5.
It feels like this decision was rushed and not well thought out on how it would impact actual consumers of the library.
cheenamalhotra commentedon Mar 25, 2025
@henkkelder @mason-mcglothlin
Can you please elaborate on what warnings are you seeing when you migrate and multi-target to .NET Framework 4.8 and .NET Runtime 8.0 as well? Maybe in a new issue to get the right attention?
mason-mcglothlin commentedon Mar 25, 2025
I don't think a new issue is appropriate, as this seems directly related to Microsoft's decision to drop support for .NET Standard.
I'm not multitargeting. I'm using .NET Standard, which is the recommended way of sharing code .NET Framework and .NET projects.
These are the warnings:
HPS.Presentation.Data and GR.GrmWebAppSharedLogic target netstandard2.0. HPS.Presentation.Web targets .NET Framework v4.7.2.
cheenamalhotra commentedon Mar 25, 2025
And what happens when you multi-target your projects? I guess I also would like to know what challenges do you face when multi-targeting v/s targeting .NET Standard 2.0?
mason-mcglothlin commentedon Mar 25, 2025
Then I get all the complications that multi-targeting entails. My .NET Framework 4.7.2 app is using the older style csproj, not the newer SDK style. The older style csproj can't easily consume a multitargeted class library. And .NET Upgrade Assistant doesn't provide a way to change it to SDK style once I've used .NET Upgrade Assistant to utilize Yarp proxy. I'd have to modify it by hand, in a large code base that's around two decades old. This is an excellent example of the complexities that you're forcing customers to take on when you force them to multitarget. I'm sure there's plenty of other customers that will feel the hassle of multitargeting in various ways. Whereas before it was easy: follow Microsoft's recommendation of using .NET Standard.
As @MichelZ pointed out multiple times, .NET Standard is still the recommended tool to use when a library needs to be consumed by .NET Framework and .NET. The need for .NET Standard may be dwindling down, but it's not gone. There are plenty of customers stuck on .NET Framework or slowly trying to migrate off of it. You've jumped the gun by trying to drop support for .NET Standard this early. The benefits listed at the start of the issue don't seem to outweigh the ensuing havoc this is going to force consumers of Microsoft.Data.SqlClient to deal with.
henkkelder commentedon Mar 25, 2025
I saw the same warnings mason-mcglothlin saw.
Also, my website is a .NET 4.8.1 project. The upgrade tool warns me that it cannot upgrade the project to an SDK style project. So I sit in the same boat as mason. I wouldn't know how to implement multi targetting.
mason-mcglothlin commentedon Mar 25, 2025
It seems to consume a multitargeted class library in the same VS solution from an older csproj (non SDK style) isn't supported. And there is no support for converting an old ASP.NET project to the newer SDK style csproj.
Summary of my options as I see it:
ErikEJ commentedon Mar 25, 2025
@mason-mcglothlin Is the multi target code in your ASP.NET project or in a seperate library? If it is in a seperate library, converting to SDK style should be simple.
You can also link files, and have two project files sharing the same files, so no "redundant code"
mason-mcglothlin commentedon Mar 26, 2025
I attempted to multitarget the class library, then have the old ASP.NET app consume the class library, which results in compiler warnings. Like I said, consuming multitarget class library from the old style csproj doesn't seem to be supported. Nor is updating an old ASP.NET app to use the new SDK style csproj. That leaves us in the predicament I described above.
Because one library among the hundred or so my app consumes decides to drop .NET Standard support, now you're asking to to either multitarget in a platform that doesn't support or to painfully link all the files across two class libraries?
You have a lot of customers that consume Microsoft.Data.SqlClient from .NET Standard, and there's a good chance that .NET Standard is used to support legacy .NET Framework apps alongside .NET Core/.NET apps. Because you wanted to simplify the library, now you're forcing all this pain back onto the consumers. The right thing to do here is clear: support .NET Standard as long as .NET Framework is still a supported platform.
That, or Microsoft needs to take on the work of having old ASP.NET projects be able to consume multitarget class libraries from the same VS solution.
HamsterExAstris commentedon Apr 6, 2025
@mason-mcglothlin What specific warnings do you get when you multitarget? I just tried making a new MVC5 project and had no warnings when I added a reference to a multitargeted class library.
GreenWaves400 commentedon Jul 2, 2025
.NET Standard 2.0 is now supposedly back as of Microsoft.Data.SqlClient 6.1-preview2, which was just released, and is supposedly going to stay from that point on, in the final 6.1.0, 7.x etc. versions.
It would be good, however, for people to check if all .NET implementations that support and implement .NET Standard 2.0 are actually working, beyond just .NET Framework and .NET [Core], as there may be runtime surprises.
GreenWaves400 commentedon Jul 25, 2025
OK, so for anyone else unaware, actual support for .NET Standard 2.0 in MDS 6.1.0+ is a hoax (or scam, whichever term is more fitting), please see the latest comments on this issue for more information:
#3115
In short, this ridiculous MDS circus, as well as (now extremely underhanded) crusade against .NET Standard itself, goes on. I should have listened to my own advice from February 5, and I hope others will, as well: