In May we reported Microsoft wants to run WinForms and WPF on .NET Core 3.0. In order to facilitate this, they are building a new tool that will allow you to vote on which APIs they need to port to .NET Core. But this isn't a direct vote; it is based on what APIs are being used by your application.
The tool they use for this is called the Portability Analyzer. Previous versions of this tool were used for voting on features needed for console and ASP.NET applications. When running the GUI version of the tool, you'll need to select a directory. If you paste in the name of an exe or dll, the analyzer will not run correctly.
We should remind you that WinForms and WPF are not going to be cross-platform under this initiative. The goal here is to allow Windows developers to benefit from the deployment and performance advances being made in .NET Core.
This isn't to say that cross-platform UI isn't a long-term possibility. It may be possible to port the Mono/Linux version of WinForms to .NET Core. Or the XAML-based Avalonia project may gain traction. And there is certainly interest in having some kind of cross-platform GUI available from the developers commenting on the .NET Core 3 announcement.
There isn't a complete list of APIs under consideration, but Immo Landwerth was able to share this information,
At a high-level, we've decided that:
- Remoting will not come to .NET Core (ever)
- We won't enable partial trust/CAS/sandboxing on .NET Core (ever)
- We won't bring System.Web, WF, WCF hosting in the .NET Core 3.0 time frame but depending on customer feedback we'll do it later.
I believe virtually everything else is a function of how many people are impacted by it and whether we can make it fit for 3.0.
In the comments, developers listed some of the APIs they most wanted. Jan Friedrich writes,
WCF Hosting would be the only thing missing for porting our apps to .net core. We have 15 different applications hosting WCF.
Ryan echoes that thought,
Most of my applications are fine but the one thing missing is WCF. I know that's in discussion so I figured I would throw my weight behind it. I'm using bi-directional TCP to talk between an app on the client and an app in a terminal services remote session. I could probably switch it over to a websocket implementation but I'd appreciate not expend the resources on it immediately (even though I've already been considering it due to a feature request that would require a major rework of the service definitions anyways)
InfoQ will be covering the server-side WCF debate next week.
