Drop support for .NET Standard

[Varorbc]

• Carries a different tree of dependencies, making dependency management more complex
• Gets rid of special case code for .NET Standard
• Increases the ability to merge .NET and .NET Framework classes
• Library already supports the .net framework and .net core framework multi target framework, and .net standard is no longer required
• Xamarin and .NET Core 3.x are essentially EOL'd by .NET 5+.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[GerardSmit]

.NET Standard 2.0 is necessary for .NET Framework (and maybe https://gitlab.winehq.org/wine-mono/mono)
.NET Standard 2.1 is necessary for Unity
Maybe there are more platforms that I'm not aware of.

Unity is currently moving to .NET (Core), when that transition is done you could deprecate 2.1, but 2.0 isn't going anywhere soon.

We still have Microsoft products that use .NET Framework. There is not an EOL of .NET Framework yet, but if there will be it'll fall under the OS lifecycle. For Windows Server 2022 that's in 2031. Visual Studio 2022 also uses .NET Framework and is EOL in 2032. And there are a lot of applications outside Microsoft that still use .NET Framework.

Multi-targeting .NET Framework and .NET (Core) brings other problems:

• You can't build the library on Mac/Linux without NuGet package Microsoft.NETFramework.ReferenceAssemblies
• You can't run tests at all on Mac/Linux (or you need to run them in Mono 6, which is an extra runtime you need to install and doesn't have all the .NET Framework features)

With multi-targeting .NET Standard and .NET (Core) you don't have these problems.

[julealgon]

While WebForms is still officially supported, I just cannot agree with this. If NET Standard was dropped, it would dramatically restrict our ability to share modern code with our old ASP.NET WebForms project.

[richlander]

@terrajobst @ericstj

[Varorbc]

According to the document, the mono corresponding to Netstandard will not receive investment in the future, and xamarin. * also ended support on May 1st this year, so it is time to abandon Netstandard support.

[kasperk81]

We still have Microsoft products that use .NET Framework.

are they moving to .net core or have they moved already in their latest releases? if windows server 2025 and 2028 are also going to use .net framework, then it's "not before 2050 (at least)" or "never". companies who haven't moved from web form era will continue to stick with "whatever works" policy, those are not worth the continuous support.

[Varorbc]

Using these packages is untested if the target framework is older than the minimum supported version.

runtime/eng/packaging.targets

Lines 121 to 133 in 8d24ba3

	<!-- Include a netstandard compat error if the project targets both .NETStandard and
	.NETCoreApp. This prohibits users to consume packages on an older .NETCoreApp version
	than the minimum supported one. -->
	<ItemGroup>
	<NETStandardCompatError Include="netcoreapp2.0"
	Supported="$(NetCoreAppMinimum)"
	Condition="$(TargetFrameworks.Contains('netstandard2.')) and
	($(TargetFrameworks.Contains('$(NetCoreAppMinimum)')) or $(TargetFrameworks.Contains('$(NetCoreAppPrevious)')) or $(TargetFrameworks.Contains('$(NetCoreAppCurrent)')))" />
	<NETStandardCompatError Include="net461"
	Supported="$(NetFrameworkMinimum)"
	Condition="'$(NetFrameworkMinimum)' != '' and $(TargetFrameworks.Contains('netstandard2.0')) and
	($(TargetFrameworks.Contains('$(NetFrameworkMinimum)')) or $(TargetFrameworks.Contains('net47')) or $(TargetFrameworks.Contains('net48')))" />
	</ItemGroup>

[Varorbc]

We still have Microsoft products that use .NET Framework.

are they moving to .net core or have they moved already in their latest releases? if windows server 2025 and 2028 are also going to use .net framework, then it's "not before 2050 (at least)" or "never". companies who haven't moved from web form era will continue to stick with "whatever works" policy, those are not worth the continuous support.

@kasperk81 now it is a multi targetframework, and the. NET framework is not affected,

[huoyaoyuan]

Existing .NET Standard versions will be supported forever, because we need to load everything that's loadable now.
There will be no new .NET Standard versions, as announced.

There's nothing actionable here.

[terrajobst]

@Varorbc

Our strategy follows what you're asking us to do: by default, new features are only available in netX.0 where X is the next release. The reason is similar to what you said, it massively reduces the friction and allows us to ship features more quickly. More details are in my old blog post The future of .NET Standard.

However, we still need to support .NET Framework customers. While we don't ship new versions of .NET Framework, we do maintain a set of libraries that can be consumed from .NET Framework. We do this for various reasons:

• .NET Framework customers need to be able to talk to Azure. The Azure client libraries have very similar needs to ASP.NET Core and thus need a way to use certain features on .NET Framework, for example, Span<T>, IAsyncEnumerable<T>, and JSON serialization.

• Visual Studio is a .NET Framework application. We need to share a great deal of code with VS; while some of this code can run out-of-proc in .NET Core, some code doesn't, for example, the C# and VB compilers are also hosted in-proc. Again, we want these to use some of more fundamental features (such as ECMA metadata, immutable collections) so we make certain features available.

And based on customer requests we make other components available as .NET Standard packages well.

Practically, I don't see this change any time soon -- .NET Framework will likely be supported for as long as Windows is supported. And as long as a ton of our customers use it, we'll likely have to make some features available for it.

[Varorbc]

@terrajobst I don't understand why removing netstandard2.0 would affect NetFramework. Isn't NetFrameworkMinimum already included in the target framework?

runtime/src/libraries/Microsoft.Extensions.Caching.Abstractions/src/Microsoft.Extensions.Caching.Abstractions.csproj

Line 4 in 063ae05

<TargetFrameworks>$(NetCoreAppCurrent);$(NetCoreAppPrevious);$(NetCoreAppMinimum);netstandard2.0;$(NetFrameworkMinimum)</TargetFrameworks>

[terrajobst]

Are you asking why we don't just drop support for building for .NET Standard in this repo if we can just multi-target between .NET Core and .NET Framework?

If so, then the reason is simply to allow customers to build a single library for both .NET Framework and .NET Core. As soon as we only ship multi-targeted packages here then everyone will have to multi-target. Multi-targeting is a lot harder than targeting .NET Standard 2.0.

[Varorbc]

The goals corresponding to Netstandard 2.0 have all ended support. Is it really necessary to support it? This is a thought-provoking question.

.NET Standard	[1.0]	[1.1]	[1.2]	[1.3]	[1.4]	[1.5]	[1.6]	[2.0]	[2.1]
.NET Core	1.0	1.0	1.0	1.0	1.0	1.0	1.0	2.0	3.0
.NET Framework	4.5	4.5	4.5.1	4.6	4.6.1	4.6.11	4.6.11	4.6.11	N/A2
Mono	4.6	4.6	4.6	4.6	4.6	4.6	4.6	5.4	6.4
Xamarin.iOS	10.0	10.0	10.0	10.0	10.0	10.0	10.0	10.14	12.16
Xamarin.Mac	3.0	3.0	3.0	3.0	3.0	3.0	3.0	3.8	5.16
Xamarin.Android	7.0	7.0	7.0	7.0	7.0	7.0	7.0	8.0	9.5
Unity	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	TBD
Universal Windows Platform	8.0	8.0	8.1	10.0	10.0	10.0.16299	10.0.16299	10.0.16299	TBD

[Varorbc]

SQL client has recently droped support for netstandard

dotnet/SqlClient#2340 (comment)

[terrajobst]

The goals corresponding to Netstandard 2.0 have all ended support. Is it really necessary to support it? This is a thought-provoking question.

There is no new version of .NET Standard; 2.1 was the final version and 2.0 is the last version implemented by .NET Framework. Hence, if you want to build a library that works on both .NET Framework and .NET Core, you need to target .NET Standard 2.0.

If you want to build a binary that supports .NET Framework and .NET Core, then you might as well build for .NET Standard 2.0 as the API intersection between .NET Core/.NET Framework is effectively the same, but you don't need to build twice and bloat your package.

[Varorbc]

You can see from nuget that the most downloaded packages do not use netstandard for single-target framework, but are multi-target frameworks

[julealgon]

@Varorbc

You can see from nuget that the most downloaded packages do not use netstandard for single-target framework, but are multi-target frameworks

Wasn't it the point that multi-targeting is much harder (on the library developer) than just targeting .NET Standard 2.0?

If you don't have a super advanced library and want to easily target both new and "full" framework, surely you'd opt for targeting .NET Standard 2.0.

[kasperk81]

transitioning from:

<TargetFramework>netstandard2.0</TargetFramework>

to:

<TargetFrameworks>net47;net8.0</TargetFrameworks>

isn't necessarily complicating the project. when dealing with more complex scenarios, where different frameworks have specific requirements or features, you might indeed need to incorporate conditional compilation (#if NET #if !NET). but the VS experience is pretty much the same: "API is not available in .NET Standard" build error becomes "not all targets support the API".

[terrajobst]

Let's step back. What exactly is being asked here?

1. Do you want us to deprecate .NET Standard all-up, i.e. in the SDK and VS?
2. Do you want us to stop building libraries targeting .NET Standard from this repo?

These are related but not the same thing. Either way, my question is why you want this to happen. If you don't want to target .NET Standard, then don't. But I don't understand what is gained by advocating for this repo/.NET all up to remove it. It's mostly a giant breaking change.

To put things in perspective: 1/3 of all packages on nuget.org target .NET Standard. When you remove .NET Standard from your package, it has ripple effects for everyone depending on it (if they target .NET Standard).

[Varorbc]

I want only the second, and 1/3 of the packages you mentioned are for netstandard, How much of this 1/3 is just a single target framework? Perhaps most packages are multi target framework.

The current netstandard is merely a collection of target frameworks that are no longer supported. For a better future, I believe we should drop support for it.

[kasperk81]

@Varorbc many netstandard libraries on NuGet, especially those that depend on other netstandard libraries, would be left without support if netstandard is abandoned. Additionally, having multiple framework assemblies in a NuGet package, as opposed to a single assembly, is one of the practical reasons for maintaining netstandard.

reducing reliance on netstandard by migrating existing .NET Framework projects to newer frameworks, particularly those challenging transitions like Windows Forms to Razor views, is a constructive path forward. This could gradually decrease the relevance of netstandard over time.

[terrajobst]

I want only the second, and 1/3 of the packages you mentioned are for netstandard, How much of this 1/3 is just a single target framework? Perhaps most packages are multi target framework.

I don't know how many of them target multiple framework, but my gut feel is many, at least half of those, if not more.

But keep in mind that NuGet is the "leaf" node in this; there are a ton of libraries that exist in application projects to share code between, say, a .NET Framework desktop app and an ASP.NET Core backend. I have quite a few of those. And there I mostly get away with not having to multi-target. Even if the entire NuGet ecosystem were to multi-target you'd still break this scenario.

My view is: as long as .NET Framework is still relevant, people will want a way to build a single framework project that they can use to share code with .NET Core.

[julealgon]

But keep in mind that NuGet is the "leaf" node in this; there are a ton of libraries that exist in application projects to share code between, say, a .NET Framework desktop app and an ASP.NET Core backend.

This is precisely our case. We have tons of libraries targeting NET Standard 2.0 on a 150-project solution comprising of various types of Web APIs, Windows Services and Console Application type projects, most of which we intend to migrate to .NET8, but some of which can't be migrated, as they currently use WebForms. We envision we'll have at least some NET Standard 2.0 libraries for a good while even after performing this NET8 (or NET9) migration.

[Varorbc]

The current netstandard is merely a collection of target frameworks that are no longer supported.

A few years ago, when netstandard still had target frameworks that were supported, it wouldn’t have made sense to drop it. But now, with .NET 10 coming up, we really should consider this. We’ve given plenty of time for the move from .NET Framework to .NET Core, and we can’t keep supporting it forever. If .NET 10 doesn’t drop support, we should definitely think about doing it later.

[julealgon]

We’ve given plenty of time for the move from .NET Framework to .NET Core

What are you talking about @Varorbc . I'll repeat: WebForms is still supported and it is limited to .NET Framework 4.8. Microsoft can't just stop supporting .NET Framework, unless they make something like CoreWebForms official and fully featured. And that's just one of the things that are tied to NET Framework.

I don't disagree with you conceptually, that we should unify on newer .NET framework versions, but I don't think that is doable today.

[GerardSmit]

I don't understand why removing netstandard2.0 would affect NetFramework. Isn't NetFrameworkMinimum already included in the target framework?

runtime/src/libraries/Microsoft.Extensions.Caching.Abstractions/src/Microsoft.Extensions.Caching.Abstractions.csproj

Line 4 in 063ae05

<TargetFrameworks>$(NetCoreAppCurrent);$(NetCoreAppPrevious);$(NetCoreAppMinimum);netstandard2.0;$(NetFrameworkMinimum)</TargetFrameworks>

I would rather see that .NET Framework 4.6.x would be removed than .NET Standard 2.0. From my understanding .NET Framework is only added because .NET Framework 4.6.x had issues with .NET Standard:

While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0

But .NET Framework 4.6.2 is supported until Jan 12, 2027 so that won't happen anywhere soon 😅

[terrajobst]

@Varorbc

A few years ago, when netstandard still had target frameworks that were supported

You're conflating a few things here:

• The framework versions in the .NET Standard table indicate the minimum version a framework needs in order to consume a given version of .NET Standard. For example, in order to consume .NET Standard 2, you need to be on .NET Framework 4.6.1. However, if you're on .NET Framework 4.8.1 you can also consume .NET Standard 2.0 - 1.0.
• This means that using .NET Standard gives you access to multiple frameworks that are supported (.NET Framework 4.8.1, .NET 8, Unity) etc.

Hence saying that .NET Standard is pointless is missing the mark.

[Varorbc]

• The source generator project should typically target the netstandard2.0 TFM, as to support their consumption within .NET Framework environments including the Visual Studio IDE and MSBuild CLI.

It solved my problem, but with libraries like SqlClient dropping support for netstandard, it’s only a matter of time before the runtime does the same. I’m not sure when that day will come.

[richlander]

it’s only a matter of time before the runtime does the same

I can assure you that @terrajobst will be (very) well-informed on that day coming (AKA, he'll be the one driving it). Clearly, that day has not come.

[Varorbc]

@richlander @terrajobst

In fact, the library for the author, is also a very painful thing
open-telemetry/opentelemetry-dotnet#3448

[fowl2]

How about… netstandard2.0.1*, that is just the slightly larger overlap between Framework 4.8.1 and .Net8, or even does some packaging/build magic to pull in polyfills on netframework to make it even closer.

/runs and hides

*pick some other name, maybe even corresponding to real .Net releases. netcompat8, netframework481+net9?

Big trade off investing more here, but the longer we leave it yes more will have jumped across the widening chasm from fx to core, but also more will be stranded… on the framework side.

[huoyaoyuan]

How about… netstandard2.0.1*, that is just the slightly larger overlap between Framework 4.8.1 and .Net8, or even does some packaging/build magic to pull in polyfills on netframework to make it even closer.

The effort of creating a new target framework is quite large. It doesn't provide enough benefit. This is definitely not an option.

[tannergooding]

Big trade off investing more here, but the longer we leave it yes more will have jumped across the widening chasm from fx to core, but also more will be stranded… on the framework side.

More APIs existing in modern .NET does not equate to an increase in complexity of users moving off of .NET Framework. The porting effort remains overall the same and the typical scenario is rather that we've made it even simpler to migrate because more APIs that were missing have been added instead. -- This is why it's often considered easier to migrate from .NET Framework to .NET 5+ than it was to migrate to .NET Core 1.0, 2.1, or 3.1; because there was a larger surface area parity between them.

The experience today ends up being that most APIs from the BCL exist and remain backwards compatible. There are some that have had behavioral changes and bug fixes that may need to be accounted for, which were generally done to better support cross platform semantics or to fix historically incorrect behavior that couldn't easily be fixed in .NET Framework (but which fixing allowed apps to be more correct, more robust, and often faster as well). There are also higher level frameworks, like ASP.NET Core, which were complete rewrites and which have their own compat/porting considerations.

There are some technologies that never made it over to modern .NET, often because they were fundamentally broken in some way and were already considered largely legacy, deprecated, or broken. These can be the largest hurdles for porting, but often have alternatives.

https://learn.microsoft.com/en-us/dotnet/core/porting/ covers much of these differences and the tooling that can help in migrating. Introducing a newer standard won't move the needle here at all.

[terrajobst]

@fowl2

How about… netstandard2.0.1*, that is just the slightly larger overlap between Framework 4.8.1 and .Net8, or even does some packaging/build magic to pull in polyfills on netframework to make it even closer.

That would probably not be possible because it likely violates framework compat rules. Since we already shipped a .NET Standard 2.1 we can't ship a .NET Standard 2.0.X that has more APIs than .NET Standard 2.1. We could, however, in principle at least, try to find the set of APIs that are in .NET Standard 2.1 and .NET Framework and ship a 2.0.1 but I don't see compelling enough evidence for that.