WCF客户端CloseAsync vs Abort（）

我正在使用可移植类库构建服务类，所有UI技术都使用这些服务类与我们的服务进行通信

这些库将支持Silverlight、Asp.Net和任何其他.NETUI技术

由于支持Silverlight，因此所有调用都必须是异步的

使用Silverlight，我可以在client.Method（）调用服务之后立即调用CloseAsync（）

然而，我发现这不适用于Asp.Net客户端

我不想在完成的代码中使用CloseAync（），因为如果进行多个异步调用，可能会遇到计时问题

我不想想出很多逻辑，比如在每个异步方法中都放一个while循环，以确保CloseAsync（）没有被调用和完成

现在，我正在测试在已完成的部分中使用Abort，一切看起来都很正常

只是好奇，是否有其他人知道我们在使用Abort时可能遇到的任何问题

谢谢

---

我们使用的是.Net 4.5。

这取决于您使用的绑定。如果您使用的是使用会话的绑定，那么调用Close[Async]将尝试首先关闭该会话（例如，使用可靠消息传递的WSHttpBinding），然后关闭连接，否则它将在服务器端保持活动状态，直到超时。如果您使用的绑定不使用会话（即BasicHttpBinding），那么它们几乎是等价的。

感谢您的回复。这些类将被编写为支持用户决定的任何绑定。对于silverlight客户端，我们可能有一个自定义二进制文件，对于WPF客户端，我们可能有一个自定义的net.tcp文件。使用该文件将基于传递给初始化函数的值。在查看状态时，似乎在CloseAsync调用后，状态立即进入关闭状态。现在，在我的初始化中，如果状态未打开或未创建，我将实例化一个新客户机。在完成的代码中，如果状态为Faulted，则使用abort，否则使用CloseAsync（）。到目前为止，这似乎适用于Silverlight和asp.net客户端。就客户端而言，它可以正常工作。但是，如果服务器中的最大会话配额较低，则可能会命中该配额（即，新客户端可能会被拒绝新会话）。只有当会话端点的流量非常大时，才会发生这种情况，因此这对您来说可能不是问题。