我正在努力与似乎不处理默认命名空间的SOAP服务进行交互，但是可以正常使用在SOAP信封级别声明的全局命名空间和命名空间前缀。
问题是WCF不在根目录下创建这些全局命名空间，而是使用明确的无前缀默认命名空间，服务显然是在阻塞。现在我知道这不是WCF的错 - 我相信WCF生成的消息是有效的XML，但是服务仍然扼杀了它。
使用WCF生成的输出如下所示：
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:Security xmlns:h="http://docs.oasis-open.org/wss/2004/01/oasis-
...
</h:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<cancelShipmentRequest xmlns="http://www.royalmailgroup.com/api/ship/V2">
<integrationHeader>
<dateTime xmlns="http://www.royalmailgroup.com/integration/core/V1">2016-03-26T01:44:37.0493801Z</dateTime>
<version xmlns="http://www.royalmailgroup.com/integration/core/V1">2</version>
<identification xmlns="http://www.royalmailgroup.com/integration/core/V1">
<applicationId>RMG-API-G-01</applicationId>
<transactionId>ozhckwej6sxg</transactionId>
</identification>
</integrationHeader>
<cancelShipments>
<shipmentNumber>TTT001908905GB</shipmentNumber>
</cancelShipments>
</cancelShipmentRequest>
</s:Body>
</s:Envelope>
哪个不起作用。
使用以下SOAP信封（在SoapUI中手动）确实可以正常工作：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:v2="http://www.royalmailgroup.com/api/ship/V2"
xmlns:v1="http://www.royalmailgroup.com/integration/core/V1">
<soapenv:Header>
<h:Security xmlns:h="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
...
</h:Security>
</soapenv:Header>
<soapenv:Body>
<v2:cancelShipmentRequest>
<v2:integrationHeader>
<v1:dateTime>2016-03-02T14:55:00Z</v1:dateTime>
<v1:version>2</v1:version>
<v1:identification>
<v1:applicationId>RMG-API-G-01</v1:applicationId>
<v1:transactionId>wftdaife96gv</v1:transactionId>
</v1:identification>
</v2:integrationHeader>
<v2:cancelShipments>
<v2:shipmentNumber>TTT001908905GB</v2:shipmentNumber>
</v2:cancelShipments>
</v2:cancelShipmentRequest>
</soapenv:Body>
</soapenv:Envelope>
两者之间的区别在于v1和v2名称空间在文档顶部全局声明，并且第二个文档中没有本地名称空间声明。
也许我错过了一些东西，但对我而言，WCF生成的XML看起来是有效的，并且在命名空间方面表示相同的文档状态。
我能说的唯一区别是声明命名空间的方式。虽然WCF版本似乎有效且产生相同的命名空间，但该服务仍抱怨无效的命名空间引用。
架构验证失败：消息架构验证失败：架构有效性错误：元素'xmlns'：不期望此元素。预期是（{http://www.royalmailgroup.com/api/ship/V2} integrationHeader）。
问题是，强制WCF在顶部而不是内联添加命名空间引用的最佳方法是什么？到目前为止，我找到的唯一方法是使用消息检查器并明确重写消息，但如果我完成所有操作，我也可以手动创建消息。
我可以尝试强制WCF使用显式名称空间前缀而不手动重写消息吗？
答案 0 :(得分：10)
所以这个问题的答案是创建一个自定义IClientMessageFormatter和Message，然后覆盖Message.OnWriteStartEnvelope()以显式写出Soap文档根目录下的所有命名空间。然后，渲染文档重用这些名称空间，而不是在子元素上显式分配名称空间。
要为此工作创建3个类：
OnWriteStartEnvelope() 这是所有三个代码：
public class RoyalMailCustomMessage : Message
{
private readonly Message message;
public RoyalMailCustomMessage(Message message)
{
this.message = message;
}
public override MessageHeaders Headers
{
get { return this.message.Headers; }
}
public override MessageProperties Properties
{
get { return this.message.Properties; }
}
public override MessageVersion Version
{
get { return this.message.Version; }
}
protected override void OnWriteStartBody(XmlDictionaryWriter writer)
{
writer.WriteStartElement("Body", "http://schemas.xmlsoap.org/soap/envelope/");
}
protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
this.message.WriteBodyContents(writer);
}
protected override void OnWriteStartEnvelope(XmlDictionaryWriter writer)
{
writer.WriteStartElement("soapenv", "Envelope", "http://schemas.xmlsoap.org/soap/envelope/");
writer.WriteAttributeString("xmlns", "oas", null, "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
writer.WriteAttributeString("xmlns", "v2", null, "http://www.royalmailgroup.com/api/ship/V2");
writer.WriteAttributeString("xmlns", "v1", null, "http://www.royalmailgroup.com/integration/core/V1");
writer.WriteAttributeString("xmlns", "xsi", null, "http://www.w3.org/2001/XMLSchema-instance");
writer.WriteAttributeString("xmlns", "xsd", null, "http://www.w3.org/2001/XMLSchema");
}
}
public class RoyalMailMessageFormatter : IClientMessageFormatter
{
private readonly IClientMessageFormatter formatter;
public RoyalMailMessageFormatter(IClientMessageFormatter formatter)
{
this.formatter = formatter;
}
public Message SerializeRequest(MessageVersion messageVersion, object[] parameters)
{
var message = this.formatter.SerializeRequest(messageVersion, parameters);
return new RoyalMailCustomMessage(message);
}
public object DeserializeReply(Message message, object[] parameters)
{
return this.formatter.DeserializeReply(message, parameters);
}
}
[AttributeUsage(AttributeTargets.Method)]
public class RoyalMailFormatMessageAttribute : Attribute, IOperationBehavior
{
public void AddBindingParameters(OperationDescription operationDescription,
BindingParameterCollection bindingParameters)
{ }
public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
{
var serializerBehavior = operationDescription.Behaviors.Find<XmlSerializerOperationBehavior>();
if (clientOperation.Formatter == null)
((IOperationBehavior)serializerBehavior).ApplyClientBehavior(operationDescription, clientOperation);
IClientMessageFormatter innerClientFormatter = clientOperation.Formatter;
clientOperation.Formatter = new RoyalMailMessageFormatter(innerClientFormatter);
}
public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
{ }
public void Validate(OperationDescription operationDescription) { }
}
大部分是仪式和样板代码。关键代码段是OnWriteStartEnvelope，其中实际名称空间被连接，SerializeRequest格式化程序连接到WCF管道，ApplyClientBehavior，其中消息格式化程序附加到实际操作。
为了解决这个问题，我在服务接口上将该属性添加到了client方法 - 在本例中是Reference.cs中生成的WCF客户端。
// CODEGEN: Generating message contract since the operation cancelShipment is neither RPC nor document wrapped.
[System.ServiceModel.OperationContractAttribute(Action="cancelShipment", ReplyAction="*")]
[System.ServiceModel.FaultContractAttribute(typeof(MarvelPress.Workflow.Business.RoyalShippingApi.exceptionDetails), Action="cancelShipment", Name="exceptionDetails")]
[System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(contactMechanism))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(baseRequest))]
[RoyalMailFormatMessage()]
MarvelPress.Workflow.Business.RoyalShippingApi.cancelShipmentResponse1 cancelShipment(MarvelPress.Workflow.Business.RoyalShippingApi.cancelShipmentRequest1 request);
从WCF生成的消息现在看起来与预期一样，所有名称空间都在文档顶部定义：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:v2="http://www.royalmailgroup.com/api/ship/V2" xmlns:v1="http://www.royalmailgroup.com/integration/core/V1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Header xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<h:Security>...</h:Security>
</s:Header>
<soapenv:Body>
<v2:cancelShipmentRequest>
<v2:integrationHeader>
<v1:dateTime>2016-04-02T01:04:50.4122473Z</v1:dateTime>
<v1:version>2</v1:version>
<v1:identification>
<v1:applicationId>RMG-API-G-01</v1:applicationId>
<v1:transactionId>fshrxevdnc7n</v1:transactionId>
</v1:identification>
</v2:integrationHeader>
<v2:cancelShipments>
<v2:shipmentNumber>TTT001908905GB</v2:shipmentNumber>
</v2:cancelShipments>
</v2:cancelShipmentRequest>
</soapenv:Body>
</soapenv:Envelope>
有关更多信息和通用命名空间添加格式化程序，请在此处查看我的相关博文：http://weblog.west-wind.com/posts/2016/Apr/02/Custom-Message-Formatting-in-WCF-to-add-all-Namespaces-to-the-SOAP-Envelope