构建 Silverlight 企业应用程序时的冒险 - 第 41 部分

在这篇文章中，我们将深入探讨这个微小的改动，它导致了 Silverlight 客户端和我们的 Web 服务之间 WCF 通信中出现了一个奇怪的错误。

在上一篇文章中，我提到我们即将发布一个新产品。我很高兴地报告，我们已经成功发布，一切进展顺利，除了少数小问题。我还描述了一个改进我们开发流程的过程。目前，我们正在全力推进这个过程。

与此同时，我们还计划了一个新版本，以修复之前提到的一些小问题，并添加一些我们之前没有时间实现的小功能。当我正在修复其中一个问题时，我遇到一个最初让我困惑的错误，但一旦我弄清楚了，它就变得微不足道了。由于解决这个问题需要大量的调试和分析，并且它突显了重构代码某些部分可能存在的问题，所以我决定与大家分享。

症状

当我测试我一直在处理的这个错误修复时，我遇到了一些奇怪的行为。Silverlight 客户端中的一些数据无法加载，或者看起来是这样。起初，我认为这可能与我所做的修复有关。

我开始调试我修改过的服务，发现由于某种原因，我们发送到服务的 ID，以便获取正确的数据，是空的。这很奇怪，因为我没有更改代码的这部分。我调试了 Silverlight 客户端，发现它确实正确地发送了 ID！这太奇怪了。我唯一能得出的结论是，ID 必须在客户端代码和 Web 服务代码之间的某个地方丢失了。

调试问题

由于这似乎是一种通信问题，我决定拿出我的老朋友 Fiddler。我重新配置客户端，通过 http://ipv4.fiddler 而不是 https:// 访问相关的 Web 服务，然后我开始重现问题。我浏览了请求，在那里，名为 Id 的参数被正确地传输，并且具有正确的值。然而，不知为何，这个值一旦到达我的 Web 服务，就消失了。

此时我唯一能得出的结论是，这必须与服务契约有关。我查看了我的服务接口，立即发现了一个潜在的问题。参数不再名为 Id，而是被重命名为 id！这是由于 FxCop 产生的一个警告造成的。它将参数名称的大小写标记为不正确，所以我进行了更正，但随后完全忘记了这件事。

简单的修复

为了解决这个问题，我确保在 .svc 代码后台中的大小写也已更正。然后，只需重新构建和发布服务，并在 Silverlight 客户端中刷新服务引用，问题就消失了。

事实证明，发布清理后的代码是一个好主意，因为这样我们可以尽早发现一些后果。它也表明，更改服务契约总是存在危险，因为它会产生可能不易察觉的不兼容性。