News
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.
[Click on image for larger view.] .NET Framework APIs in .NET Core (source: Microsoft).
Landwerth indicated the company will make it easier for developers to add their own .NET Framework APIs to open source projects.
"We're looking into releasing more of the .NET Framework code base under the MIT license on GitHub to allow the community to create OSS projects for technologies we're not intending to bring to .NET Core. For example, there already are community projects for CoreWF and CoreWCF.
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:
Q: "Does that mean we won't get LambdaExpression.CompileToMethod in .NET Core? I had hoped it was simply delayed because of assembly dependency issues (it's currently hidden behind a feature flag)...
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."
About the Author
David Ramel is an editor and writer at Converge 360.