WCF操作上下文
我正在开发一个 WCF 服务，如果出现错误，我想序列化该服务上调用的原始方法中的传入参数。 我正在使用 IErrorHandler 来捕获所有异常。
我最初的想法是，将序列化参数存储在 OperationContext.IncomingMessageProperties 中，以便可以从 HandleError 方法访问它。 但是，由于这不是在原始线程上运行，我相信 OperationContext 将为 null，因此我正在考虑从 ProvideFault 方法访问它。
这看起来可行吗？ 它可以与 OneWay 服务呼叫一起使用吗？
I'm developing a WCF service and if there is an error I want to serialize the incoming parameter from the original method that was called on the service. I am using IErrorHandler to catch all exceptions.
My initial thoughts were that I will store the serialized parameter in OperationContext.IncomingMessageProperties so that I can access it from the HandleError method. However, as this isn't run on the original thread I believe the OperationContext will be null, so I am considering accessing it from the ProvideFault method.
Does this seem feasible? And will it work with OneWay service calls?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定我真的可以在这里为您提供很多帮助，但让我尝试一下：
在您的客户端上，您的代码基本上调用一个方法并向其传递参数。 然后，客户端上的 WCF 堆栈将其转换为带有标头和所有内容的 SOAP 消息（通常带有 XML 正文，但也可以是二进制的），然后通过线路将该消息发送到服务器进行处理。
然后，服务器尝试将该消息反序列化为对象，并尝试调用服务器实现对象上的消息。 服务器对象上的该方法很可能再次具有与客户端相同的参数 - 但是，调用有可能在该方法被调用之前就失败。
所以我想说的是：你不能依赖你的服务器端方法及其参数确实被调用的事实 - 可能存在身份验证、消息格式、丢失标头等问题否则，这会导致服务器端失败并在调用服务器端方法之前抛出异常。
最后，在 IErrorHandler 中，我无法知道如何获取消息和/或方法及其参数 - 您所能获得的只是服务器上发生的错误，您可以使用它来将其转变为 SOAP 错误。
您可以做的 - 在客户端和服务器端 - 是创建一个插入 WCF 堆栈的新行为，并记录正在调用的方法和传递给它们的参数 - 通过实现一个实现
IParameterInspector接口。 但只有当客户端和服务器上的消息被正确反序列化并且服务器端方法真正被调用时，才会被调用。查看其中一些链接，了解有关 WCF 扩展性的详细信息：
希望这会有所帮助！
马克
Not sure I can really help you much here, but let me try:
on your client, your code basically calls a method and passes it parameters. The WCF stack on the client side then converts that into a SOAP message (typically with an XML body, but could be binary, too) with headers and all and then sends that message across the wire to the server to be processed.
The server then attempts to deserialize that message into an object and attempts to call a message on a server implementation object. That method on the server object will most likely have the same parameters again, as the client - however, there's a possibility that the call will fail before that method even gets called.
So what I'm trying to say is: you can't rely on the fact that your server-side method with its parameters really gets called - there might have been a problem with e.g. authentication, the message format, a missing header or something else, that causes the server side to fail and throw an exception even before the server-side method ever gets called.
In the end, in the IErrorHandler, there's no way I would know of to get a hold of the message and/or the method and its parameters - all you can get are the error that occured on the server, and you can use that to turn it into a SOAP fault.
What you could do - both on the client and the server side - is create a new behavior that plugs into the WCF stack, and that records the methods being called and the parameters being passed into them - by implementing a class that implements the
IParameterInspectorinterface of WCF. But that only will get called if the message on the client and the server will get properly deserialized and the server-side method really gets called.Check out some of these links for more info on WCF extensibility:
Hope this helps a bit!
Marc