Two days ago, Immo Landwerth, a program manager on the .NET team announced that the community is concluding the .NET Framework API Porting project. They also plan to release more of the .NET Framework codebase under the MIT license on GitHub to allow the community to create OSS projects for technologies that will not be brought to .NET Core. For example, there already are community projects for CoreWF and CoreWCF.
"We’re looking into releasing more of the .NET Framework code base under MIT to allow the community to create OSS projects for technologies we’re not [bringing] to .NET Core. For example, there already are community projects for CoreWF and CoreWCF." https://t.co/dCmDg8LuFb
— Scott Hanselman (@shanselman) October 15, 2019
In May, this year, Microsoft announced that the future of .NET will be based on .NET Core. At Build 2019, Scott Hunter stated that AppDomains, remoting, Web Forms, WCF server, and Windows Workflow won’t be ported to .NET Core.
“With .NET Core 3.0, we’re at the point where we’ve ported all technologies that are required for modern workloads, be it desktop apps, mobile apps, console apps, web sites, or cloud services,” Landwerth writes.
.NET Core 3.0 released last month includes added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs. Also, about 62K APIs to .NET Core that doesn’t exist in the .NET Framework. On comparing the total number of APIs, .NET Core has about 80% of the API surface of .NET Framework.
“Since we generally no longer plan to bring existing technologies from .NET Framework to .NET Core we’ll be closing all issues that are labeled with port-to-core,” Landwerth further mentions.
Post this announcement on GitHub, a lot of GitHub users enquired more about this change in the .NET community. A user asked, “Is CSharpCodeProvider ever going to happen in Core? The CodeDom API arrived somewhere in the 2.x timeframe, but it’s a runtime fail even under 3.0 – are we going to need to re-write for some kind of explicitly Roslyn scripting?” To this, Landwerth replied, “CSharpCodeProvider is supported on .NET Core, but only the portions that deal with CodeDOM creation. You can’t compile because this would require a compiler and the .NET Core runtime doesn’t include a compiler (i.e. Roslyn). However, we might be able to do some gymnastics, like reflection, where the app can pull that in. Still tracked under #12180.”
.NET 5 is (implementation wise) just a differently branded .NET Core 4:
– we'll skip 4 to avoid confusion with .NET Framework 4.x
– we'll drop "Core" to indicate that this is the successor for both .NET Core as well as .NET Framework
— Immo Landwerth (@terrajobst) October 14, 2019
To know more about this announcement in detail, read the official GitHub post.