News

.NET Standard 2.1 Announced with 3,000 New APIs

Microsoft just announced .NET Standard 2.1, its first update in more than a year as it plays catch-up with the .NET Core implementation, which is about to hit v2.2.

The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations. One of those implementations is the open source, cross-platform .NET Core, which has already hit v2.1 and will soon advance to v 2.2.

".NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services," Microsoft said Immo Landwerth, program manager on Microsoft's .NET team, in announcing .NET Standard 2.0 in August of last year.

.NET Standard
[Click on image for larger view.] .NET Standard (source: Microsoft).

Today (Nov. 5), he announced .NET Standard 2.1, with some 3,000 APIs planned to be added. He said the definition of the new version is ongoing, providing no completion date, though the GitHub site currently reports it's 84 percent complete.

Landwerth listed some highlights of the new version, including the addition of Span<T>, introduced in .NET Core 2.1, which also includes many other APIs destined for .NET Standard 2.1. "Since .NET Core was open sourced, we've added many small features across the base class libraries such as System.HashCode for combining hash codes or new overloads on System.String," he said. "There are about 800 new members in .NET Core and virtually all of them got added in .NET Standard 2.1."

One .NET implementation that won't be moving to support .NET Standard 2.1 is the traditional Windows-entrenched .NET Framework, another indication of Microsoft's reduced focus on the 16-year old platform, which has upset some .NET developers.

Here's what Landwerth had to say about that:

.NET Framework is the implementation of .NET that's installed on over one billion machines and thus needs to remain as compatible as possible. Because of this, it moves at a slower pace than .NET Core. Even security and bug fixes can cause breaks in applications because applications depend on the previous behavior. We will make sure that .NET Framework always supports the latest networking protocols, security standards, and Windows features.

.NET Core is the open source, cross-platform, and fast-moving version of .NET. Because of its side-by-side nature it can take changes that we can't risk applying back to .NET Framework. This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don't want to do that.

Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.

That led one developer to comment (unedited): ".NET Framework IS DEAD. NetStandard 2.1 will not be supported in .NET 4.8 and a few days earlier a statement that there'll be no further extension to .NET Framework. Does MSFT have the backbone to officially write that .NET Framework is dead?"

Microsoft has repeatedly assured developers that .NET Framework is not dead and will continue to receive some updates.

"We will continue to update the .NET Framework, but you'll see it slowing down," said Microsoft's Beth Massi in a recent Visual Studio Live! conference keynote address. "So you shouldn't feel pressured to move off .NET Framework, but just know that it's going to be much more highly targeted compatible fixes kind of going forward and we recommend that all new development that you start on .NET is on .NET Core if possible."

UPDATE: Since this article was originally published, Landwerth responded to the above reader comment:

.NET Framework is a Windows component and hence will be supported for a very long time to come. And supported means we'll fix bugs and add features that are required for compliance, for example, new crypto standards such as TLS changes.

But what is also true is that the rate of innovation in .NET Framework has to slow down in order to reduce breakage. In that sense, you should generally expect that most new features will only become available on .NET Core (and derived platforms, such as Xamarin, Mono, and Unity as they build from the same sources as .NET Core).

At the time of this writing, the discussion is ongoing at the bottom of today's blog post.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube