帮助调试 WCF答案

【问题标题】：Help debugging WCF帮助调试 WCF
【发布时间】：2010-09-12 23:55:06
【问题描述】：

我是 WCF 编程的新手，我发现学习过程相当令人沮丧。据我所知，默认情况下，WCF（和 WPF）会隐藏错误。到目前为止，我遇到了以下问题，并且从 Visual Studio 或运行时得到的指示基本上为零（除了我的应用程序无法正常工作）：

服务引用不是最新的（为什么 VS 不自动执行此操作？）；
无法序列化服务方法中的类型；
服务尝试传递的数据超出默认值。

大概有一些简单的方法可以让我（开发人员）看到这些问题。如果有人能告诉我它是什么，我将不胜感激（数小时的谷歌搜索没有提供有效的答案）！

如果有人知道，我也希望能解释一下为什么 WCF 和 WPF 的默认行为是悄悄隐藏这样的错误。至少可以这么说，这似乎很奇怪。

【问题讨论】：

【解决方案1】：

我猜你误解了 Web 服务的基本概念。 WCF 是用于构建 Web 服务的 API。与 RPC 相比，Web 服务应该是独立使用的。这意味着您可以在不知道将要使用它的应用程序的情况下创建 Web 服务（您可以将 Web 服务公开给 Internet 或业务伙伴）。这与 RPC 有很大的不同，其中客户端和服务大部分时间是一起构建的。基于基本的安全实践，默认情况下服务异常不会发送给客户端。您不想将内部信息暴露给未知的客户。

对于您的问题：

服务参考不是最新的：是的，这对于版本控制非常重要。我可以构建新版本的 Web 服务并使用旧的客户端代码。如果您正在构建客户端和服务，并且您确信新版本的客户端和服务将始终在同一时间部署，您可以使用 Andrew 的建议。

类型无法序列化：Web 服务正在使用可互操作的格式进行数据交换。你认为编译器应该如何知道类型是否可序列化？它是否应该在每次构建期间运行所有数据类型的序列化？正如 John 所建议的，这可以通过适当的测试策略轻松发现。

服务尝试传递更多数据然后客户端允许：你的意思是什么？你的意思是服务可以传递客户不知道的附加字段，因为新版本的服务？在这种情况下，您抱怨的是最重要的版本控制功能之一。还是您的意思是服务可以发送比客户端允许的更大的消息？在那种情况下，服务应该如何知道未知客户端允许的大小？ MaxReceiveMessage 大小用于防御拒绝服务攻击，由接收方控制。如果您需要在通信中处理动态消息大小，则必须对其进行编码。

隐藏错误：默认情况下，每个服务在其行为中都有此配置：

<serviceDebug includeExceptionDetailInFault="false" />

只需将此更改为 true 添加 WCF Tracing + socket tracing 和 WCF Message logging，您将获得 MS 在 .NET 中为开发人员提供的最佳诊断工具。

【讨论】：

感谢您的回复，如果您能进一步解释，我将不胜感激，因为您提出的观点我在其他地方听到过。 (1) WCF 与异步 RPC 有何不同？每个操作都有一个名称和一个签名（这些是这些类型的参数，this是this的结果> 类型）。如果我更改此规范，我将看不到客户端如何继续与我的服务交互。 (2) 接口是强类型的。 WCF 确切地知道所涉及的类型。如果我在期望字符串的地方传递一个 int，我真的应该得到一个错误指示。
[cont.] (3) 如果我的服务或客户端尝试发送的数据多于通道配置在单个消息中传输的数据，它也应该告诉我。我可以看到允许 any 异常通过接口是多么糟糕，但我看不出解释请求的格式错误或无法以其他方式提供服务的方式如何为攻击者提供有用的信息。跨度>
也就是说，我一定会尝试您的建议 - 非常感谢。 WCF 无疑是一个很棒的工具，我一直在努力找出我的应用程序无法运行的原因。
WCF 和 RPC 之间通常没有区别，因为您可以在 WCF 中创建类似于 Web 服务的 RPC。这只是WCF的应用。但是您也可以创建 SOA 服务或 REST 服务——这样的应用程序不可能使用 RPC （如远程处理）。但是像 Web 服务这样的 RPC 仍然更加面向契约。合同采用可互操作格式（WSDL + XSD），因此您可以在 .NET 中编写服务并在 Java 中轻松使用它。
版本控制有一定的规则。您不能更改操作名称，但可以删除不需要的参数或添加不需要的参数。如果您在预期字符串的位置传递 int，则除非您正在处理未使用接口的原始消息，否则您会得到异常。防御 DoS 攻击按原样工作。在 IIS 或 ASP.NET 中完全相同。如果超出限制，您只会收到错误的请求。

【解决方案2】：

你完全错了。 WCF 不会向您隐藏错误。你肯定没有找对地方。

您是否查看过 Windows 事件日志（应用程序）？您是否打开了 WCF 跟踪？

您有必要控制更新服务参考的时间。仅仅因为您更改了合同并不意味着是时候更新对合同的每个引用。更新服务引用可能需要更改客户端代码，并且很可能需要再次对其进行测试。

您希望如何在不进行序列化的情况下了解序列化错误？如果你想确定你的序列化工作，然后创建一个序列化的单元测试！

一般来说，WCF 运行良好。与任何技术一样，您在学习时更有可能遇到挫折。

【讨论】：

他是，但对他很容易。 :) 当你第一次开始做 WCF 时，当你没有得到详细的异常时，你的第一反应是“WTF”。但 WCF 跟踪的建议是关键。
约翰，谢谢你的建议。我在某些方面不同意你的观点，特别是不使用标准错误报告机制（即异常）确实在我的书中算作错误隐藏。如果我的应用程序不工作，我不应该玩捉迷藏来找出原因。
至于序列化错误，我希望 RPC 机制能够保证这些不会发生。这就是拥有静态检查类型系统的全部意义所在。此外，我无法独立于客户端升级接口的服务器端。我当然想同时更新两者。
我相信你是对的，WCF 很棒。但是，我挑战您解释默认的错误报告行为是如何有帮助的。事件日志中的错误消息也可能是用 Martian 编写的。
只是为了给我温和的咆哮一些背景：近 20 年前，我曾在 / 使用过 ANSA 和 Corba RPC 系统，我记得当出现问题时，它们非常清楚。

【解决方案3】：

你的一个观点的答案：

“添加服务参考”功能在您自己不编写或维护服务合同时很有用。如果服务、客户端和服务合同在同一个解决方案中，最好不要依赖自动生成的服务引用。它们不会自动更新这一事实只是原因之一。

请参阅 this presentation 以深入了解。

【讨论】：

非常感谢您的建议，安德鲁；有机会我会去看看的。