Announcement: .NET Core 3.0 concludes the .NET Framework API porting project

[terrajobst]

We started in .NET Core 1.0 with a very minimal API set that only included ~18K of the .NET Framework APIs. With .NET Standard 2.0, we tried to make it much more viable to share code between .NET Framework, .NET Core, and Xamarin which resulted in approximately 38K .NET Frameworks APIs being available in .NET Core 2.0. We also built the Windows Compatibility Pack which made another 21K .NET Framework APIs available to .NET Core, resulting in almost 60K additional APIs. And in .NET Core 3.0 we 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.

It’s also worth pointing out that we added about 62K APIs to .NET Core that don’t exist in .NET Framework. If we compare their total number of APIs, .NET Core has about 80% of the API surface of .NET Framework.

We announced that the future of .NET will be based on .NET Core. And 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 that desktop apps, mobile apps, console apps, web sites, or cloud services. 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.

Simultaneously, 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.

We’d like to thank everyone who filed issues with requests for APIs being ported. Those issues allowed us to prioritize and close the gaps that prevented people from porting to .NET Core.

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

[raffaeler]

Any chance to see the original codebase for WCF server published (not maintained)? An archived repository with all the sources would be perfect for forking.

[terrajobst]

@raffaeler

Any chance to see the original codebase for WCF server published (not maintained)? An archived repository with all the sources would be perfect for forking.

Yes. AFAIK we've already exposed all of WCF in the MIT licensed .NET Framework code. That's why I wrote this:

Simultaneously, 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.

[raffaeler]

Thank you @terrajobst, I already knew about CoreWF and CoreWCF, but some customers have strong policies about the origin where the sources are published, that is why I asked.
While practically WCF is not "hidden", for legal reasons it would be easier for them to see the sources published (even if unmaintained) in a GitHub repository.

Thanks

[ltrzesniewski]

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

[terrajobst]

While practically WCF is not "hidden", for legal reasons it would be easier for them to see the sources published (even if unmaintained) in a GitHub repository.

Note that WCF is already part of Reference Source.

However, the code in in reference source doesn't include any of our internal build infrastructure, so it can't be used directly by anyone. So whatever community is working on it will have to copy the relevant sources into a new repo and create a build environment for it (project files, packaging etc). That's basically what CoreWCF is (even though it has seen a lot of other changes too).

[terrajobst]

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

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.

[ltrzesniewski]

Thanks, that's good to know! It's already logged under #20270 BTW.

[willdean]

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?

[terrajobst]

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 #18768.

@willdean, have you tried just changing the code that invokes the compiler? With Roslyn that shouldn't be too hard and in contrast to CodeDOM in .NET Framework doesn't even require writing the source files to disk.

[kolappannathan]

Any plans for local speech synthesis, if you are not porting System.Speech?

[willdean]

@terrajobst The problem with #18768 is that it doesn't really help us choose between A. changing our existing code to support Core and B. merely waiting for Core to support our existing code. It's not really a very active issue (14 months since any substantive activity) and is neither a 'no we're never going to make this work' nor a 'yes it's on the roadmap for 5.0 (or whenever)'.

I was only really trying to find out if this latest announcement offered any additional clarity on that.

As you say we can "just change the code" to use Roslyn explicitly, it would just be nice if we didn't need to.

[terrajobst]

@kolappannathan

Any plans for local speech synthesis, if you are not porting System.Speech?

I'll ask for details.

@willdean

The problem with #18768 is that it doesn't really help us choose between A. changing our existing code to support Core and B. merely waiting for Core to support our existing code.

I think the idea of #18768 is to make the existing CodeDOM API work. The only additional gesture for the developer might be to add some kind of NuGet package that glues CodeDOM and Roslyn together.

It's not really a very active issue (14 months since any substantive activity) and is neither a 'no we're never going to make this work' nor a 'yes it's on the roadmap for 5.0 (or whenever)'.

Usage of this APIs fairly low (~0 on NuGet, ~1% in API Port telemetry). We've prioritized APIs with more usage. Also, this API is mostly convenience; the workaround is to invoke Roslyn on the generated source files.

As you say we can "just change the code" to use Roslyn explicitly, it would just be nice if we didn't need to.

Right, and there is nothing wrong with wanting this. It's just that (1) it's a low usage API and (2) it has a reasonable workaround and (3) supporting requires more work than a straight port.

[dotMorten]

Could you also opensource System.Devices? This bit isn't on reference source.

[coxp]

Really disappointed with MS on this one. I don't expect a full port of WCF server-side but surely having the ability to create SOAP endpoints is still necessary for any enterprise projects on any platform. Telling us to use the .NET Framework or a proxy service just doesn't cut it. Yes, there are attempts at open-source projects (SoapCore and CoreWCF) but neither work and are incompatible with clients created against .NET framework SOAP services. I'd love to see the telemetry on how WCF was used in general as I'd imagine most services are just simple basic HTTP endpoints and that doesn't seem like much work to port.

[jhaygood86]

Yes, there are attempts at open-source projects (SoapCore and CoreWCF) but neither work and are incompatible with clients created against .NET framework SOAP services.

@coxp -- Do you have any details about what makes SoapCore incompatible? My employer did a porting effort that required minimal code changes to go from .NET Framework WCF to SoapCore (actually required LESS code), and didn't require ANY client side or contract changes (we literally just changed the host name from our web server farm running IIS to our app server running since we self-hosted the SoapCore version via Kestrel not using IIS). Our contract is also stored in an internal nuget package we reference from servers and client, and we referenced the same package in both the WCF/IIS version and the SoapCore/Kestrel version. I looked through the SoapCore repo and didn't see any issues filed by you.

[Clockwork-Muse]

@jhaygood86 - I dunno what they might be referencing, maybe it's one of the more niche messaging options?

I remember hearing a while ago that historically it was difficult to get .NET and Java to work together for SOAP, but that may no longer be the case.

[coxp]

@jhaygood86 Although not raised by myself, this seems to be the exact issue that we are suffering from. DigDes/SoapCore#344.

We can't regenerate the client-side code because we don't own those services.

Additionally we have the issue that SoapCore is not really production ready (and to be fair is not v1 yet and even the author hopes that MS will make the project redundant). We built a service on SoapCore 0.9.9.1 and that version is not backwards compatible with newer versions and breaks existing clients if we upgrade to the latest version of SoapCore.

I don't want WCF. I just want MS to provide a way to create basic HTTP soap endpoints on the new stack. We're still creating new services as SOAP endpoints because that is what our clients require.

[duaneking]

@terrajobst We really need System.Speech support; It feels like the blind or visually disabled community is really being ignored here, either intentionally or by mistake, and a remote service in azure for speech is the absolute WORST answer you could give me for this as it MUST be all running locally to even be useful or functional for many disabled people. Honestly, System.Speech should have had the same priority in .net as System.Console because for many, its the exact same thing when you cant see.

I'm really confused here because I'm not seeing the sort of inclusiveness or leadership on this issue that I would normally expect from MSFT, and the overall tone on accessibility issues when I have reached out to teams in the past - both internally and externally - has not been inclusive.

[dotMorten]

@duaneking can't you use the sdk contracts to use the WinRT apis for that?
https://blogs.windows.com/windowsdeveloper/2019/04/30/calling-windows-10-apis-from-a-desktop-application-just-got-easier/

[duaneking]

@dotMorten Sadly, No, I don't like that idea at all as it violates the fundamental ideal of inclusion that MSFT has publicly stated is its goal here. It does not fit the same use cases, does not provide the same functionality, would require API/Code changes, and would effectively force sighted/non-sighted segregation by namespace and functionality. I don't feel that's a fair solution as it would only make things worse for the disabled.

System.Console is simple to you or anybody looking at this because you can see it. But imagine if you had no monitor hooked up to your computer, or if you somehow simply could not turn it on and didn't have the ability to do so every day. How would you interact with the computer if you could not see it? So yes, a computers ability to speak "hello world" should just be as simple as printing it to the screen. We need the same simplicity. Using the same API as System.Speech so that code can all be reused without needing to be rewritten from scratch to support WinRT and its dependency chain would be a great start.

Right now I can only get this simplicity on only Linux, only using non-msft software; It doesn't exist on windows at all in terms of net standard. It would be nice to be able to use windows to develop things that the disabled - remember I'm talking about blind kids that want to code, too! - can actually use, without first needing to deal with WinRT/Internal Windsows API's that kills their ability/desire to even try.

[terrajobst]

Right now I can only get this simplicity on Linux using non-msft software.

Does this mean you require a version of System.Speech that can work on Linux? We didn't bring System.Speech to .NET Core because the team that owns it considers it replaced. But even if we would provide it: it's a very slim wrapper over Windows COM APIs which means it wouldn't work on Linux.

[duaneking]

All you need is a interface. If it uses the System.Speech API and can be referenced as System.Speech in code using System.Speech and code using System.Speech can run without modification, platform support only needs to exist for windows, especially if its open source.

[dotMorten]

Lots of APIs were removed because they wrapped old deprecated Windows com APIs no longer supported (GeoCoordinate APIs is another example). They've been replaced by newer, better and supported WinRT APIs that you can use instead. Why don't you want to use something that's more up to date and supported for the users you refer to? (And if you need, create that compat interface you're talking about).

[terrajobst]

@duaneking would you mind opening a new issue specifically asking for speech synthesis? I'd like to keep this discussion generic here.

[duaneking]

@terrajobst Sure, I can file a bug, Should I make it here or in a different project? I noticed this is a repeated issue and others have tried to support this, as the bug exists multiple times.

[duaneking]

@dotMorten I get the idea that APIs that are newer are sometimes considered to be better, but really they often are not. My experience with the WinRT apis is that they are often a grab bag of good and evil, often had weird API interfaces that forced incorrect assumptions, didn't play well outside of these assumptions, and in the cases I was forced to use them FORCED me to violate SOLID because the API itself was leaky. Maybe they have improved in the last half a year, but I just don't want to subject a blind person to that hell when all they want to do is make a hello world "console" app because they cant see the screen anyway. It just feels like this would be harmful.

[jkotas]

Let's continue the discussion about System.Speech in https://github.com/dotnet/runtime/issues/34963