WCF 客户端返回错误“远程服务器返回错误：NotFound。”
我正在将 WPF 应用程序迁移到 Silverlight。我的 WPF 应用程序使用 BackgroundWorker 访问 Web 服务。 服务时出现任何错误，我会在回调中收到大量错误消息，例如
There was no endpoint listening at http://localhost:8080/services/registration
that could accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details.
在我的 Silverlight 应用程序中，我正在异步访问相同的 Web 服务，现在我的错误消息不是很有用，例如：
The remote server returned an error: NotFound.
如果访问Web 服务没有改变 - 我可以在 Fiddler 上看到来自服务器的故障。所以问题是如何在 Silverlight 客户端上获取更详细的错误消息。
我在 Silverlight 应用程序中的回调如下所示（我正在从 e.Error.Message 访问错误消息）：
private void AuthenticateUserCallback(object sender, AuthenticateUserCompletedEventArgs e)
{
if (e.Error != null)
{
this.StatusMessage = e.Error.Message;
}
...
}
I am migrating a WPF application to Silverlight. My WPF application accesses a Web Service using BackgroundWorker. If there is any error while accessing the web service I get an extensive error message in my callback, for example
There was no endpoint listening at http://localhost:8080/services/registration
that could accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details.
In my Silverlight application, I am accessing the same web service asynchronously and now my error messages are not very useful, for example:
The remote server returned an error: NotFound.
The web service has not changed - I can see the faults coming from the server on Fiddler. So the question is how can I get more detailed error messages on the Silverlight client.
My callback in Silverlight application looks like this (I am accessing the error message from e.Error.Message):
private void AuthenticateUserCallback(object sender, AuthenticateUserCompletedEventArgs e)
{
if (e.Error != null)
{
this.StatusMessage = e.Error.Message;
}
...
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是浏览器堆栈的限制，导致 SL 无法访问完整的异常消息。请参阅此处的 MSDN 文章
该方法是将异常包装成有意义的错误（这意味着客户端将始终获得 HTTP OK 200）并在客户端执行自定义异常处理。
This is limitation with Browser stack due to which SL cannot access the complete exception message. Look at MSDN article here
The approach is to wrap exception into meaningful faults (which means client will always get HTTP OK 200) and perform custom exception handling on the client side.