WCF net.tcp 服务器断开连接 - 如何在客户端正确处理？
我现在遇到了一个有点烦人的问题。 我有一个 Silverlight 4 应用程序（默认情况下运行 OOB）。它使用 WCF 和 net.tcp 作为与服务器通信的方式。 客户端使用 wcf 客户端代理的中央实例。只要服务器端一切保持运行，一切就都很好。
如果我在所有事情中间终止服务器，我就会淹没在客户端的大量异常中（连接丢失、通道故障等）。
现在我正在寻找一种以干净且集中的方式处理此问题的方法（如果可能的话）。
SL 应用程序在 App.cs 中有一个中央客户端对象 (public static MyClient Client { get;set;})，该对象在应用程序启动时进行初始化。
知道如何正确处理客户端对象上的任何连接问题吗？
I'm stuck with a bit of an annoying problem right now.
I've got a Silverlight 4 application (which runs OOB by default). It uses WCF with net.tcp as means of communicating with the server.
The client uses a central instance of the wcf client proxy. As long as everything keeps running on the server side, everything's fine.
If i kill the server in the middle of everything, i drown in an avalanche of exceptions on the client side (connection lost, channel faulted etc etc).
Now i'm looking for a way to handle this in a clean and centralized way (if centralized is possible).
The SL app has one central client object sitting in App.cs (public static MyClient Client { get;set;}), which gets initialized on application start.
Any idea how to properly handle any connectivity problems on the client object?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您提到您正在使用 WCF 客户端代理的中央实例。
如果是这种情况，那么当服务器发生错误时，代理将进入“Faulted”状态。为了使事情集中化，您可以将客户端代理转换为
ICommuicationObject并将事件处理程序附加到Faulted事件，该事件处理程序会在事件发生时使用新代理替换出现故障的代理。火灾。关于集中访问资源的线程安全性的常见警告适用！
You mention that you're using a central instance of the WCF client proxy.
If this is the case, then when a server error occurs, the proxy will go into the Faulted state. To keep things centralized, you could cast the client proxy to an
ICommuicationObjectand attach an event handler to theFaultedevent which replaces the faulted proxy, with a new proxy when the event fires.The usual warnings about thread-safety for centralized access to resources apply!
我想我找到了一个可行的（尽管不是集中式的）解决方案。它不需要用 try/catch 块来混乱代码，它似乎需要的是对 event.Error 属性进行空检查。如果连接发生问题，该属性始终不为空。仅当您尝试访问 event.Result 时才会引发异常。
它可能不是最漂亮的解决方案，但到目前为止它似乎有效。
也许有一种更优雅的方式......
I think i found a workable - though not centralized - solution. Instead of cluttering the code with try/catch blocks, all it seems to need is a null-check for the event.Error property. If something happened to the connection, this property is always not null. The exceptions only get raised if you try to access event.Result.
It may not be the most beautiful solution, but it appears to work so far.
Perhaps there is a more elegant way though...