Microsoft continues to be non-committal on the topic of server-side WCF. After giving the impression that server-side WCF is a dead technology, a Microsoft employee quickly stated patience is needed, while not actually contradicting the earlier announcement.
While client-side WCF has been available since the beginning, for years Microsoft has refused to port the server-side of WCF to .NET Core. Aside from team size, no explanation has ever been given for why this is the case for the library as a whole. The source code is available on Reference Source and most of the bindings are suitable for cross-platform work.
Note there are some security options and bindings that are Windows-only (e.g. named pipes, MSMQ). But the Windows Compatibility Pack already handles that for other libraries.
The current round of complaints began when Scott Hunter wrote,
After .NET Core 3.0 we will not port any more features from .NET Framework. If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. If you are a remoting or WCF Server developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC, which provides cross platform and cross programming language contractbased RPCs). If you are a Windows Workflow developer there is an open source port of Workflow to .NET Core.
This has upset many .NET developers who have been saying REST is not a replacement for WCF. The same arguments can be made for gRPC, which from the view-point of a WCF user is just a binding that ignores the rest of what WCF offers. Simply put, neither serves the role of an abstract communication framework, which was the main intention of WCF. (Not to mention the need for supporting WS-*/SOAP for legacy and contractual reasons.)
Github commenter dgxhubbard writes,
Scott's statement says one thing, "Have fun with gRPC!". I wish the people who made this decision had to also code with gRPC and replace some of the WCF server services, to see exactly what this statement means. .Net core 3 and beyond adoption is going to be pot hole filled road. We are going to have to rewrite our services to mimic WCF, so our adoption of .Net Core 3 and beyond will be shelved for awhile.
Chris Benard concurs,
Same here. I don't see how gRPC is anywhere near a drop-in replacement. One of the huge selling features of WCF was ability to share DLLs between server and client side, filled with models and interfaces for the service contracts. gRPC relies on proxy generation, from what I can see. Some of our services store copies of serialized objects that we re-hydrate for use later. I don't see how gRPC is going to enable any of that.
I really don't want to go down the road of manually using NetDataContractSerializer and forcing the bytes down a gRPC pipe or something (does NetDataContractSerializer even exist in Core? I hope/assume so It does not. But DataContractSerializer does). One more thing not supported from the full Framework).
The contracts aren't the huge deal to me. It's the model sharing between server/client with the same DLLs.
Also, the ability to have multiple endpoints on a single ServiceHost. We can have TransportSecurity on one Endpoint and MessageSecurity on another. We've used this to update the way we do security on the endpoints. None of this appears to be supported by gRPC.
Not to mention, we have institutional customers who have to open outbound ports one by one, and we can't just migrate on the same port to the cluster with gRPC.
This all means .Net Core is out of reach on the server side for quite some time. Thank god I've never been using WS-Security or anything on the client side, so I'm not stuck there, yet, I don't think. However, I'd have to retarget the server-side DLLs that are shared to netstandard2.0 and then try to see how that works between Core WCF client and Framework WCF server.
TLDR: This is a nightmare. I will sorely miss the full Framework.
Double edit: LOL gRPC doesn't even support named pipes for local cross-process remoting. Things I took for granted in WCF... Wow.
Mixed Messages
Matt Connew of Microsoft has made a couple comments implying there is a future path for WCF users,
That statement from Scott isn't talking about this WCF repo as WCF is now separate from .NET and is more like an external library than a part of the framework. Although I can't say anything at this time specifically about server-side WCF, the door isn't closed for porting more WCF features over and we do want to support more scenarios.
This was recently reiterated by Matt,
The volume of opinions that was made after //Build was heard, I promise. Please have a little bit more patience. Large corporate cogs sometimes can be big and heavy and take a lot of effort to turn, and then can be slow moving. Scott Hunter announced on twitch during Build that something is in the works, and it is.
However, recently Stephen Bonikowsky of Microsoft seems to have contradicted this,
As for the WCF Server side, there are no plans for it to be included as part of this repo. There is a lot of interest in server side and you can follow the ongoing discussion in #2695 particularly comments made recently in there by @mconnew
This could mean anything from simply a separate repo for server-side WCF to a complete redesign, as we saw when LINQ-to-SQL was replaced by Entity Framework. We simply don’t know and Microsoft isn’t ready to reveal their plans.
