No More .NET Framework APIs Will Be Ported to .NET Core, Microsoft Says

The old, proprietary, Windows-only .NET Framework has given all it can give to the new cross-platform, open-source platform of the future, .NET Core.

In a GitHub issue, Microsoft announced the end of the .NET Framework-to-.NET Core API porting project. From now on, new tech will come from elsewhere.

"With .NET Core 3.0, we're at the point where we've ported all technologies that are required for modern workloads, be that desktop apps, mobile apps, console apps, web sites, or cloud services," said Immo Landwerth, .NET program manager. "That's not to say that we don't have any gaps or opportunities for new technologies, but we generally believe we won't be finding them in the .NET Framework code base anymore. Moving forward, we're focusing our resources on incorporating new technologies."

With the Sept. 23 release of .NET Core 3.0, and a v3.1 preview already out, the last vestiges of .NET Framework -- such as desktop development -- have been added.

The three-year .NET Core project started out with about 18,000 .NET Framework APIs in v1.0, with subsequent releases bringing that total to more than 120,000, which represent more than half of the total number of .NET Framework APIs. An additional 62,000 or so non-.NET Framework APIs were added.

That latter project was spurred by Microsoft's decision to not bring Windows Communication Foundation from .NET Framework to .NET Core, rather emphasizing the use of alternate technologies such as ASP.NET Core Web APIs or gRPC (Google RPC, which provides cross-platform and cross-programming language contract-based remote procedure calls).

With the API project concluded, Microsoft is closing all issues labeled with port-to-core and invited developers to discuss the issue at dotnet/corefx#41769.

With Landwerth's post now two days old, that discussion has already started, with developers asking about the inclusion of various APIs and features. One of those comments prompted Landwerth to explain that specific individual APIs may still be incorporated in some cases, as shown in this exchange:

Immowerth: "This announcement is about technologies (e.g. expression trees or RefEmit itself). I see minor convenience APIs like CompileToMethod still as fair game, because they can be thought of as an evolution of .NET Core. So it's really more about the motivation: we wouldn't add this API just because it existed in .NET Framework. But by the same token, we wouldn't reject it, just because it already existed in .NET Framework either. So feel free to file an issue for that."

Featured

This week saw two third-party vendors of dev tools -- UX and UI toolkits and controls -- release new offerings that include support for two of Microsoft's main open source frameworks, the cross-platform .NET Core 3.1 and Blazor, which allows for creating browser-based web applications with C# instead of JavaScript.

Clustering non-numeric -- or categorial -- data is surprisingly difficult, but it's explained here by resident data scientist Dr. James McCaffrey of Microsoft Research, who provides all the code you need for a complete system using an algorithm based on a metric called category utility (CU), a measure how much information you gain by clustering.