微软在与服务器端WCF相关的问题上仍然没有什么进展。在人们看来，服务器端WCF似乎已经是一项过时的技术。微软的一名员工表示，这需要点耐心，这与之前的声明并不矛盾。

虽然客户端WCF从一开始就可用，但多年来微软一直拒绝将WCF的服务器端移植到.NET Core。除了团队规模问题之外，从来没有人解释为什么没有将它们看成一个整体看待。源代码可以在Reference Source上找到，而且大多数绑定都是跨平台的。

注意，有一些安全选项和绑定只针对Windows的（例如命名管道、MSMQ），不过Windows Compatibility Pack已经为其他库解决了这些问题。

在Scott Hunter给出如下的描述后，引起了用户新一轮的抱怨：

在.NET Core 3.0之后，我们将不再从.NET Framework中移植任何功能。如果你是一个Web Forms开发人员，并且希望基于.NET Core构建一个新的应用程序，我们将推荐使用Blazor，它提供了最接近的编程模型。如果你是一个Remoting或WCF Server开发人员，并且希望基于.NET Core构建一个新的应用程序，我们建议使用ASP.NET Core Web API或gRPC，它们提供基于跨平台和跨编程语言的RPC。如果你是一个Windows Workflow开发人员，可以使用开源的Workflow .NET Core移植版本。

这让很多.NET开发人员感到不安，他们一直认为REST不能替代WCF。gRPC也是一样，从WCF用户的角度来看，gRPC只不过是一个忽略了WCF提供的其他功能的绑定。简单地说，它们都没有发挥抽象通信框架的作用，而这正是WCF的主要意图。（更不用说因为一些遗留问题和合约原因需要支持WS-*/SOAP了）。

GitHub用户dgxhubbard写道：

Scott的声明说了一件事：“使用gRPC愉快！”我希望做出这个决定的人也能使用gRPC来编写代码，并替换掉一些WCF服务器服务，看看这句话到底意味着什么。我们将不得不重写我们的服务来模拟WCF，所以我们对.NET Core 3和更高版本的采用将被搁置一段时间。

Chris Benard表示赞同：

我表示赞同。我不认为gRPC会是一个很好的替代方案。WCF最大的卖点之一是能够在服务器端和客户端之间共享DLL，提供了丰富的服务契约模型和接口。在我看来，gRPC依赖于代理生成。我们的一些服务会保存序列化对象的副本，以便稍后重用它们，我不知道gRPC将如何实现这些。

我真的不想再手动使用NetDataContractSerializer，然后把字节强制放到gRPC管道或其他什么东西上（.NET Core中有NetDataContractSerializer吗？我希望或者假设是不存的，但DataContractSerializer存在）。

合约对我来说不是什么大事，它是具有相同DLL的服务器/客户端之间的模型共享。

此外，还有需要在单个ServiceHost上提供多个端点的能力。我们可以在一个端点上具有TransportSecurity，在另一个端点上具有MessageSecurity。我们用它来更新端点上的安全性，但gRPC似乎都不支持这些。

更不用说我们的用户必须一个接一个地打开出向端口，而且我们不能只使用gRPC将同一个端口迁移到集群。

这一切都意味着.NET Core在很长一段时间内都无法在服务器端使用。感谢上帝，我从未在客户端使用过WS-Security或其他任何东西，所以我没有掉进这个坑。但是，我必须重新定义netstandard2.0共享的服务器端DLL，然后尝试了解核心WCF客户端和WCF服务器之间的工作原理。

这真是一个噩梦，我几乎失去了整个框架。

gRPC甚至不支持用于本地跨进程远程的命名管道，而这在WCF中我认为是理所当然的事情…

微软的Matt Connew发表了几条评论，暗示了WCF用户的未来之路：

Scott的这句话并不是在讨论WCF代码库，因为WCF现在与.NET是分开的，它更像是一个外部库，而不是框架的一部分。虽然目前我还不能对服务器端WCF做任何特别的说明，但是将更多的WCF特性移植到服务器的可能性还是有的，我们确实希望支持更多的场景。

Matt最近重申：

我保证，在Build大会之后，会有大量的意见被听取，请再耐心一点。大型企业的轮子有时可能又大又重，需要很大的力气才能转动它们，而且可能会移动得很慢。Scott Hunter在Build大会上布有一些东西正在开发中，而且确实如此。

然而，微软的Stephen Bonikowsky似乎提出了反驳观点：

在WCF服务器端方面，并没有计划将其包含在代码库中。不过，人们对服务器端非常感兴趣，你可以关注#2695中正在进行的讨论，特别是@mconnew最近在那里发表的评论。

这可能意味着这是一个从服务器端WCF单独代码库到整体的重新设计，就像我们在使用Entity Framework替换LINQ-to-SQL时看到的那样。现在还说不清楚，而且微软还没有准备好公布他们的计划。

查看英文原文：Unclear Plans for Server-Side WCF Continues to Frustrate .NET Developers

创作场景

服务器端 WCF 开发计划不明，开发者表示遗憾