It’s about two years ago that I announced .NET Standard 2.0. Since then we’ve been working hard to increase the set of .NET Standard-based libraries for .NET. This includes many of the BCL components, such as the Windows Compatibility Pack, but also other popular libraries, such as the JSON.NET, the Azure SDK, or the AWS SDK. In this blog post, I’ll share some thoughts and numbers about the .NET ecosystem and .NET Standard.
Adoption by the numbers
In order to track adoption, we’re looking at nuget.org. On a regular interval, we check whether new package versions add support for .NET Standard. Once a package ID does, we stopped looking at future versions. This allows us to track when a package first adopted .NET Standard.
For the purposes of measuring adoption in the ecosystem, we’ve excluded all packages that represent the .NET platform (e.g. System.*) or were built by Microsoft, e.g. Microsoft.Azure.*. Of course, we track that too, but as part of pushing first parties to adopt .NET Standard.
This is what the adoption looks like:
- On nuget.org:
- 47% of the top one thousand packages support .NET Standard
- 30% of all packages support .NET Standard (about 48k out of 160k packages)
- Generously adding trendlines, we could expect ~100% by around 2022
- Trendlines border on using a magic 8 ball, so take these figures with a big jar of salt.
- We’ll likely never get to a 100% but it seems to suggest that we can expect maximum reach within the next two to three years, which seems realistic and is in line with our expectations.
What should I do?
With few exceptions, all libraries should be targeting .NET Standard. Exceptions include UI-only libraries (e.g. a WinForms control) or libraries that are just as building blocks inside of a single application.
In order to decide the version number, you can use the interactive version picker. But when in doubt, just start with .NET Standard 2.0. Even when .NET Standard 2.1 will be released later this year, most libraries should still be on .NET Standard 2.0. That’s because most libraries won’t need the API additions and .NET Framework will never be updated to support .NET Standard 2.1 or higher.
This recommendation is also reflected in the .NET library guidance we published earlier (taken from the cross-platform targeting section):
✔️ DO start with including a
netstandard2.0target.Most general-purpose libraries should not need APIs outside of .NET Standard 2.0. .NET Standard 2.0 is supported by all modern platforms and is the recommended way to support multiple platforms with one target.
There are some reasons why you may want to update to .NET Standard 2.1. The primary reasons would be:
- Wide support for
Span<T>- We’ve added various new methods across the BCL to support span-based APIs for writing allocation free code
- New language features
IAsyncEnumerable<T>IndexandRangeexpressions- default interface methods
Summary
.NET Standard adoption is already quite high, but it’s still growing. Please continue to update the packages you haven’t updated yet. And when creating new packages, continue to start with .NET Standard 2.0, even after .NET Standard 2.1 has shipped.
Happy coding!
Is there any reason to use something < .NET Standard 2.0 for new projects?
I think by next year this graph is going to go the other way- .NET Standard usage will start decreasing. As others have said, .NET Standard will largely be irrelevant when .NET 5 comes out. It’s already vastly less useful than it used to be given that .NET Framework will never implement 2.1+.
And the lagging nature of the Standard has always made it far less useful than it could’ve been. I think in a few years we’ll look at it as another transitional, flawed experiment like PCL was.
> As others have said, .NET Standard will largely be irrelevant when .NET 5 comes out.
I doubt it. See this comment:
https://devblogs.microsoft.com/dotnet/update-on-net-standard-adoption/#comments-2697
>>> .NET Standard will largely be irrelevant when .NET 5 comes out.
I think you underestimate the volume of code that is not currently/easily portable to .NET Core. netstandard2.0 will be the last & only version that can be targeted when attempting to modernize a framework-era codebase. As dependent libraries target higher versions of the standard/netcore3.0/.NET 5 or C# >= 8.0, these applications will be stuck on library versions that are no longer actively maintained. It will take a lot of effort in a lot of places to ensure that bugfixes/security updates make their way into the older version branches.
There’s quite a lot of confusion around targeting libraries to .NET Standard. With hindsight, I think it would have made more sense to name it something like: “API Level 1”, “API Level 2”, etc similar to the approach Android uses, as this makes it clear that you’re targeting an API set rather than a specific framework version.
Isn’t this adoption kinda mute as microsoft is going to merge Core, Standard, and Framework back into one package? https://devblogs.microsoft.com/dotnet/introducing-net-5/
Not really. See this comment:
https://devblogs.microsoft.com/dotnet/update-on-net-standard-adoption/#comments-2697