控制WCF消息体序列化

我需要创建一个模拟第三方服务的WCF服务。该服务具有非常复杂的消息和包装，因此我将在描述中对其进行简化。
我拥有该服务的WSDL并创建了代理类。但是这里出现了第一个问题：代理中的所有方法都有

[System.ServiceModel.OperationContractAttribute（Action=“”，ReplyAction=“*”）]

因此，不可能用许多方法创建WCF服务：代理中的每个方法对应一个方法，因为每个方法都必须具有唯一的操作。我认为第三方服务有一种处理所有请求的方法。我在RequestTypeBase和ResponceTypeBase上创建了这样的方法，其中包含所需的KnownType属性。所有代理类方法都有一个类型为的参数，该参数派生自RequestTypeBase。 这里是主要的问题：当WCF服务尝试反序列化消息体时，它抛出一个异常，表示预期的elementName是“Process”（处理所有请求的mega方法的名称），但现有的elementName是“RequestType1”（包含必须传递给“Process”的数据的名称类）方法作为参数）。那么我如何才能收到这样的信息？？WCF中是否有某些属性不要求methodName作为消息体的根？我甚至不明白，如果WCF已经知道调用什么方法，他需要那个方法名做什么？看起来像是动作规范的冗余

也许WCF成功处理的简单示例将有助于理解我的意思：

<s:Body>
  <TestMethod xmlns="someNamespace">
    <x>1</x>
    <str>param2</str>
  </TestMethod>
</s:Body>

1.
参数2

您可以使用“通用服务合同”在服务端完全跳过WCF反序列化：

然后自己处理接收到的消息实例的反序列化

---

如果您正在为测试目的编写某个外部服务的存根模拟（我猜这是一个很好的方法），因为您可以准确地控制响应中发送的内容。

谢谢！看来会有帮助的！我尝试了几乎相同的方法，但没有使用RequestTypeBaseOh作为消息参数，正如经常发生的那样，好的问题是答案=）的一半。我找到了有帮助的属性：[XmlSerializerFormatAttribute]将其添加到WCF服务的接口方法中哦，不，我认为XmlSerializerFormatAttribute没有任何好处-XmlSerializer只是没有抛出一个元素“Process”未找到的异常，但它会导致以null作为参数=（）调用该方法。

[ServiceContract]
public interface IUniversalRequestResponseContract
{
    [OperationContract(Action="*", ReplyAction="*")]
    Message ProcessMessage(Message msg);
}