2009-03-18 5 views
2

Ich erzeuge Client-Seite Web-Service-Code mit Svcutil. Der wsdl-Vertrag, den ich verwende, enthält einen Soap-Fehler. Wenn der Code generiert wird, scheint der Fehler in dem Namespace enthalten zu sein, der im Vertrag definiert wurde.Svcutil Soap Fault Namespace Problem

Kann jemand erklären warum?

ich einfach bin mit svcutil [Dateiname]

Beispiel WSDL:

<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://tempuri.org/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://tempuri.org/"> 
<wsdl:types> 
    <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/"> 
     <s:element name="HelloFault"> 
      <s:complexType/> 
     </s:element> 
     <s:element name="HelloWorld"> 
      <s:complexType/> 
     </s:element> 
     <s:element name="HelloWorldResponse"> 
      <s:complexType> 
       <s:sequence> 
        <s:element minOccurs="0" maxOccurs="1" name="HelloWorldResult" type="s:string"/> 
       </s:sequence> 
      </s:complexType> 
     </s:element> 
    </s:schema> 
</wsdl:types> 
<wsdl:message name="HelloWorldSoapIn"> 
    <wsdl:part name="parameters" element="tns:HelloWorld"/> 
</wsdl:message> 
<wsdl:message name="HelloWorldSoapOut"> 
    <wsdl:part name="parameters" element="tns:HelloWorldResponse"/> 
</wsdl:message> 
<wsdl:message name="NewMessage"> 
    <wsdl:part name="detail" element="tns:HelloFault"/> 
</wsdl:message> 
<wsdl:portType name="Service1Soap"> 
    <wsdl:operation name="HelloWorld"> 
     <wsdl:input message="tns:HelloWorldSoapIn"/> 
     <wsdl:output message="tns:HelloWorldSoapOut"/> 
     <wsdl:fault name="FaultName" message="tns:NewMessage"/> 
    </wsdl:operation> 
</wsdl:portType> 
<wsdl:binding name="Service1Soap12" type="tns:Service1Soap"> 
    <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> 
    <wsdl:operation name="HelloWorld"> 
     <soap12:operation soapAction="http://tempuri.org/HelloWorld" soapActionRequired="" style="document"/> 
     <wsdl:input> 
      <soap12:body use="literal"/> 
     </wsdl:input> 
     <wsdl:output> 
      <soap12:body use="literal"/> 
     </wsdl:output> 
     <wsdl:fault name="FaultName"> 
      <soap12:fault name="FaultName" use="literal"/> 
     </wsdl:fault> 
    </wsdl:operation> 
</wsdl:binding> 

Erzeugt:

namespace tempuri.org 
{ 

using System.Runtime.Serialization; 



[System.Diagnostics.DebuggerStepThroughAttribute()] 
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")] 
[System.Runtime.Serialization.DataContractAttribute(Name="HelloFault", Namespace="http://tempuri.org/")] 
public partial class HelloFault : object, System.Runtime.Serialization.IExtensibleDataObject 
{ 

    private System.Runtime.Serialization.ExtensionDataObject extensionDataField; 

    public System.Runtime.Serialization.ExtensionDataObject ExtensionData 
    { 
     get 
     { 
      return this.extensionDataField; 
     } 
     set 
     { 
      this.extensionDataField = value; 
     } 
    } 
} 

}

Aber auch andere Arten de clared im Vertrag werden ohne Namespace deklariert?

Antwort

0

Ich bin mir nicht sicher, ich verstehe, was das Problem ist ... können Sie klären?

Aus der Sicht es scheint, WCF tut das Richtige ... die generierte Klasse hat den richtigen Namespace-URI im [DataContract] -Attribut entsprechend dem Schema in dem WSDL-Fragment, das Sie zeigten.

Was haben Sie erwartet?

Update: OK, ich sehe, was Sie sagen, aber in diesem speziellen Fall ist es auch nicht unerwartet. Wenn Sie genau hinsehen, beachten Sie, dass die andere Klasse, die Sie erwähnen (HelloWorldRequest), ein Nachrichtenvertrag und kein DataContract ist. Nachrichtenverträge haben keine eigenen Namespaces, können jedoch einen Namespace für das Wrapper-Element um den Nachrichtentext angeben (siehe Eigenschaft WrapperNamespace).

In Ihrem Fall gibt der Nachrichtenkontrakt an, dass er nicht umschlossen ist, sodass der WrapperNamespace sowieso nicht zutrifft.

Update # 2: In Bezug auf den CLR-Namespace (und nicht den XML-Namespace-URI) gibt Ihnen SvcUtil eine Möglichkeit, das zu steuern; Überprüfen Sie das Argument/Namespace: documentation.

+0

Sorry, mein Punkt war keiner der anderen Typen sind in dem Namespace, in dem sie deklariert wurden. Nur die Soap-Fehler. Ich werde den Beitrag bearbeiten. Danke –

+0

Ich merke jetzt, dass ich nicht klar war, ich bezog mich auf den C# -Namespace und nicht auf den im DataContract definierten Namespace. –

+0

Vielen Dank, ich wusste über den Namespace-Switch. (Ich habe nicht geholfen, indem ich meine Frage schlecht formulierte!) Wissen Sie, warum das Standardverhalten darin besteht, die Fehler in einen CLR-Namespace und nicht in Nachrichten einzufügen? Scheint seltsam? insbesondere wenn Sie Fehler in Namespaces wie 'http: // www.domain/name/2009/03/18 'etc –

1

Sie haben die /UseSerializerForFaults verwenden Attribut auf svcutil, wird dies die XmlSerializer verursachen zum Lesen und Schreiben Störungen verwendet werden (aber nur diejenigen), anstelle des Standard DataContractSerializer (die noch für den Rest verwendet wird, von dem Zeug).

Dies scheint ein echter Fehler zu sein - mehr Infos zu meiner blog post.

+0

Was ist, wenn/UseSerializerForFaults als nicht erkannte Option signalisiert wird? – Juri