Update on .NET Standard adoption



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.0 target.

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


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

Immo Landwerth

Program Manager, .NET

Follow Immo   

Peter 2019-08-07 14:18:30
So MSFT still thinks the libs on Nuget are in any way representative for the thousands of commercial 3rd party libs in use by Enterprise/Medical/Financial etc. devs? Libs for image processing, sophisticated 3rd party WPF controls, libs for license management, libs for financial services, for payment processing. All this kind of expensive 3rd party libs we  "uncool" devs use, often are forced to use by regulation or customer contracts. None of this stuff is on Nuget and the Net Standard adaption in this area is pretty close to zero. And by the way: Would MSFT mind to finaly fix the comment system of this blog?
Jesper Jensen Nørregaard 2019-08-07 23:32:10
Hi, What is the story around C#8 and .Net Standard 2.0. Should I just use C#8, and rely on tooling to only allow usage of compatible features?
Martin Sedlmair 2019-08-08 01:24:08
The problem is that .NET Standard is always after .NET Core. So many features are still not available. Span<T> is one example. We switched to .NET Standard but then Span<T> came which is only available in .NET Core. So to be up-to-date you must need to switch to .NET Core. It would be better if .NET Standard gets updated first and then .NET Core.
Lex Mitchell 2019-08-08 04:06:23
Given that the .Net Framework is no longer supporting new versions of the Standard and .Net Core will be able to run on the Mono runtime by the time of .Net 5, it really feels that most of the point in having a separate standard has gone. I can see it being useful for a few more transitional years, but will it continue after that?
Jukka Snellman 2019-08-08 08:38:46
I also don't see the point of .NET Standard 2.1. I have tons of projects that will be stuck with .NET Framework, pending rewrite, and I'm sure I'm not the only one, considering it's no easy task. So 2.0 is definitely relevant, but once you're in .NET Core/5, might as well target that directly.
Sergiy Korzh 2019-08-09 05:25:10
Does this research include unlisted packages as well? For example, some time ago, with a major update of our library, we assigned new IDs to the NuGet packages. New packages targets .NET Standard. Old packages target .NET Framework, and, most possibly, will never target .NET Standard. We will unlist those packages in some time, so, I think, it'd be better to exclude such unlisted packages from the observation.
Andrew Witte 2019-08-09 10:44:11
It would be interesting to see how this compairs to ".NET Core" / ".NET/Mono Framework" libs vs ".NET Standard" and what new projects are choosing.
Internet Mechanic 2019-08-09 10:56:57
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/
anonymous 2019-08-10 01:58:57
This comment has been deleted.
Daniel Smith 2019-08-12 01:48:03
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.
MgSam 2019-08-12 06:28:34
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.