应用错误收集

这个问题的灵感来自Jon Skeet的问题here，在那里他询问LINQ的人们的痛点，所以我希望这个问题不合适......

WCF的第4版可能是许多人在与WCF斗争的领域之一 - 即配置。但是，从这个标记的问题集和其他论坛中，显然还有其他人在努力争取的领域。

我过去曾做过一堆博客文章和截屏视频，试图关注常见问题（例如双面打印，会话等）。我正在计划另一套，但是想要专注于导致人们出现问题的事情，即使版本4.0中的更改也是如此。

我看到的区域是

我相信还有更多，所以我想得到投入，也许我们可以确保产品团队也能获得一些反馈给人们对WCF的最大痛点

我有时会在这里和MSDN上参与，在回答了很多问题后，我的观点是人们最大的痛苦是：

配置

配置比以前更痛苦。简化配置会使很多事情变得更糟，因为在此简化之前，如果您在配置中出错，则会出现异常。今天您将在您的服务名称中输入拼写错误（或者您将忘记添加命名空间），您的服务将默默使用其他配置。

安全是一种油漆，它是一种痛苦，它将是一种痛苦。

安全本身很复杂，WCF使这更加模糊，因为其他平台上的程序员使用基于真实WS标准的共享词汇表，WCF使用自己的名称。
仅实施了安全标准的子集 - 一个失败是缺少直接在WCF中使用消化密码的UserName令牌配置文件。
在IIS中托管服务时，服务中的安全功能与IIS完全共享，并限制整个站点/虚拟目录的设置。
在IIS中托管服务时，在IIS中处理基本身份验证 - 您必须构建自定义模块以便以不同方式处理它（但如果您使用自托管，则可以直接在WCF中使用自定义用户名密码验证程序 - IIS也应该支持它）
从WSDL创建代理时，对生成安全性配置的支持不足。目前WCF最好的是自定义绑定。仅当服务也是WCF并使用自定义绑定时，客户端上的自定义绑定才有用。我们需要在安全绑定元素中提供更好的支持，以提供与代码中相对应的相同配置功能。然后，WSDL导入器应该能够使用新的绑定元素并为安全服务创建代理。一旦此类导入程序无法导入WSDL，我们将确保默认WCF不支持该服务所期望的安全性要求。

仍有很多人看不到REST和SOAP之间的区别，最常见的错误是添加REST服务的服务引用。 REST的另一个问题是它被添加到统一协议独立的API中，但REST依赖于协议并且不依赖于消息。这有望在Web-API中得到改进。

看起来新的协议或协议版本没有添加到WCF。

除非您尝试扩展现有功能，否则WCF具有很好的可扩展性。如果您决定扩展现有的实现，通常不能。例如，要使用已消化的密码添加提到的UserName令牌配置文件，您必须从头开始完全执行此操作。您无法扩展现有的用户名实现。

编辑：最后两个是我个人的痛苦。