Why isn't WCF supported in .Net Core?
Development shops that have invested heavily in WCF were left high and dry by the emerging .Net Core ecosystem. Despite some clear demand, there were no signs that Microsoft were considering putting it on the .Net Core roadmap.
A discussion on GitHub was kicked off in 2016 and closed in early 2018 after things got a little over-heated. A survey was also published in 2017 to canvass opinion. The implication was that Microsoft's priorities were elsewhere and there were no plans to formally port WCF. This has been confirmed in a recent post that names WCF along with a collection of established technologies such as WF and WPF that will never make it to the new ecosystem.
This has been a real problem for organisations who have bet the farm on WCF. Although .Net Framework applications will continue to be supported, Microsoft are shifting the focus of their attention to .Net Core which will receive the bulk of functional enhancements. Microsoft also explicitly recommend choosing .Net Core over the .Net framework if you want to build high-performing, scalable systems or leverage containerisation.
Entire corporate ecosystems have built their service integration on top of SOAP. WCF is particularly prevalent in on premise applications that integrate with a centrally-hosted service infrastructure. These environments tend to make heavy use of Microsoft's proprietary TCP bindings to provide acceptable performance as well as the various WS-* standards involved in securing communications.
Caught by the rise of REST?
This has led to howls of anguish from a development community who feel they have been left behind. You can sympathise with their pain here. For many years, WCF services were regarded as the tool of choice for application integration. The guarantee of cross-platform operability might have been a tad shaky, but developers liked the programming model and it was straightforward to build stable and scalable web services.
WCF has in part been undermined by the rising popularity of REST. The programming model in WCF is geared around operations rather than resources so it struggles to support genuinely resource-orientated, "RESTful" APIs. The best it can manage is providing a kind of faux REST, or “methods over HTTP” via the webHttp binding.
Microsoft's response to REST was to designate ASP.Net WebAPI as the platform of choice for RESTful API development. This effectively shot the whole "one programming model, any implementation" promise of WCF in the head. Now we were being told that if you want to build modern web applications then we should not be building services with WCF.
Added to this is the growing popularity of gRPC as an alternative means of contract-first development. The format allows you to define genuinely cross-platform operations and models that are tolerant to change. The HTTP2-based transport is fast and provides features such as bi-directional streaming and flow control. Microsoft are including a gRPC template in .Net Core 3.0 which does rather imply that it as a preferred technology for contract-first development.
Why hasn't WCF been ported to .Net Core?
Microsoft have open-sourced a client library for WCF, mainly to provide support for consuming SOAP based services in .Net Core. They have also made IDE tooling and command-line utilities available for generating .Net Core proxy classes from SOAP-based contracts.
A new OSS project was kicked off in June 2019 to support a port of WCF to .Net Core though this is some way from release. It remains to be seen how much support this will get and how comprehensive the port will be. The initial version will allow creating HTTP and TCP SOAP services to be created on top of the .Net Core Kestrel server. Although these appear to be the most popular use case for WCF, it is not clear how easy it will be to port existing services to the .Net Core version.
This is the nubof the problem. Given that WCF is such a sprawling and involved framework, it can be difficult to gain a consensus around what the "essential" feature set might be. It provides support for a range of different protocols, has implemented many different ws-* standards and offers a complex extensibility framework that is baked into many implementations. There is no such thing as a "standard" or "common" WCF implementation.
There may also be some practical obstacles to implementing a .Net Core WCF stack. Part of the problem is with the “W” in WCF, i.e. "Windows". Much of the work of porting WCF to a cross-platform paradigm will involve re-implementing operation system libraries, particularly in areas such as socket layers and cryptography. These are the areas of WCF that are never likely to make it through a .Net Core port.
Added to that are the various architectural debates around whether some features were good ideas to begin with. For example, transactions can encourage service coupling, ordering should arguably be solved in business logic rather than a messaging layer, and proxy generation can give rise to RPC-style services with chatty integrations. WCF evolved over a long period and not every idea or feature is universally loved.
Light at the end of the tunnel?
The fact that a .Net Core port has been accepted into the .Net Foundation should give the WCF community cause for optimism. There is a long way to go before they will be able to leverage all the good stuff in the .Net Core ecosystem.
The sheer effort required in implementing the full framework may be the main obstacle. The experience of porting the Entity Framework to EF Core may give anybody pause for thought. The project has long struggled with complaints around missing features and performance issues. The planned port of Entity Framework 6.3 to .Net Core 3.0 will only offer a “partial version” as Microsoft have recognised that "porting legacy database code [...] isn't necessarily easy".
Perhaps the real problem is that developers do not care so much about SOAP. It's the programming model exposed by WCF that developers want to see. They have become accustomed to defining a service model based on contracts and behaviours and applying a separate channel model of formats, transports and protocols. Unfortunately, this has given rise to a framework that is too big, too "Windows" and perhaps too dated to be a successful part of .Net Core.