Drop support for .NET Standard

[ErikEJ]

• .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?

[David-Engel]

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]

This combined with potentially splitting out the Azure dependency could be fantastic for the next major release.

[ErikEJ]

@NotTsunami make sure to add a thumbs up to each of the related issues. Why is this important?

[NotTsunami]

@NotTsunami make sure to add a thumbs up to each of the related issues. Why is this important?

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]

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

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

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:

• https://learn.microsoft.com/dotnet/standard/net-standard#net-standard-not-deprecated
• https://learn.microsoft.com/dotnet/standard/net-standard#when-to-target-net80-vs-netstandard

[David-Engel]

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

Use netstandard2.0 to share code between .NET Framework and all other implementations of .NET.

We already have a .NET Framework target for .NET Framework support. No need for .NET Standard for that.

Use netstandard2.1 to share code between Mono, Xamarin, and .NET Core 3.x.

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.

[Varorbc]

@ErikEJ I created the same issue at runtime.

[Farenheith]

I have a team that made a library with common code and some of them are to manipulate database operations, and this package is .net standard. It's not a problem for us to change it to .net 7, or even 8, but I wanted to ask if you know of any potential performance issue this could cause.
We're experiencing some strange performance droppings on high-concurrency scenarios, I'm researching about it and found this thread, and I thought that maybe the decision to make this library .net standard is leveling down the performance of our applications.

[MichelZ]

This one also rubs me a bit the wrong way.
I was just maintaining some of our libraries and it dawned on me that we have libraries that use SqlClient and are netstandard2.0, so we'd have to multi-target them.

Even a Microsoft .NET PM suggests to keep using netstandard:

dotnet/designs#317 (comment)

@terrajobst speaking of the dotnet framework support, I have a question, to support the dotnet framework for a new
package, do we recommend using the netstandard2.0 target or a framework target like net462?

From @terrajobst:

I generally recommend .NET Standard 2.0 for code that you want to work everywhere. If you don't use
netstandard2.0 and instead use multi-targeting (say
net462;net6.0) then all your consumers also need to multi-target, which is
extremely annoying and prone to errors.

[MichelZ]

And here's the .NET Standard Targeting Recommendations document:

If you need to produce a NuGet package that works on .NET Framework as well as modern .NET flavors then using .NET Standard 2.0 is still the best solution for you -- and your consumers.

If you drop .NET Standard and instead just multi-target for .NET Framework and .NET 5+, you force your consumers to do the same, which is generally not necessary and thus very much undesirable.

[David-Engel]

This one also rubs me a bit the wrong way. I was just maintaining some of our libraries and it dawned on me that we have libraries that use SqlClient and are netstandard2.0, so we'd have to multi-target them.

@MichelZ Do you truly have to multi-target? I know you get a warning in Visual Studio, but when deploying, you have to target .NET or .NET Framework anyway, so you will ultimately get the correct MDS DLL. I was wondering if we simply generate a ref DLL for .NET Standard, if that would be sufficient to avoid the warning in VS.

One of the difficulties of maintaining a .NET Standard implementation was actually testing it. Because we multi-target to make sure we can provide the best/widest implementation on both .NET and .NET Framework and we test those on the appropriate targets. It was hacky to swap in the .NET Standard DLL to one or both of those targets instead.

[terrajobst]

@MichelZ Do you truly have to multi-target?

If I'm building a library that wants to use SqlClient that is .NET Standard 2.0 today (and is used by both .NET Framework and .NET Core projects) then yes, I'd have to multi-target if SqlClient drops .NET Standard 2.0.