wsdl.exe Fehler: Unable Bindung importieren ‚...‘ von Namespace ‚...‘

Question

Wenn wsdl.exe auf einer WSDL läuft Ich habe, bekomme ich diesen Fehler:

  

Fehler:. Kann nicht verbindlich 'SomeBinding' von Namensraum importieren 'SomeNS'

     

  
• Unable Betrieb 'someOperation' importieren.
  
• kann nicht Diese Elemente abgeleitet werden.
  

Ich bin mit dem Dokument-wörtlichen Stil und mit dem besten Wissen und Gewissen folge ich alle Regeln.

Um es zusammenzufassen, ich habe eine gültige WSDL, aber das Tool mag es nicht.

Was ich suche ist, wenn jemand viel Erfahrung mit dem wsdl.exe Werkzeug hat und weiß, über eine geheime Gotcha, die ich nicht tun.

Answer 1

Ich habe kam über auf die gleiche Fehlermeldung. Nachdem er eine Weile graben, fand heraus, dass eine XSD-Dateien zusätzlich zu WSDL-Datei liefern kann. So enthalten / importierte XSD-Dateien zusätzlich am Ende des Wsdl Befehl .wsdl wie folgt:

  

wsdl.exe myWebService.wsdl myXsd1.xsd myType1.xsd myXsd2.xsd ...

Wsdl gab einige Warnungen, aber es hat eine ok-Service-Schnittstelle erstellen.

Answer 2

manchmal muss u ur-Code ändern. die Nachricht Teilnamen sollten nicht gleich;)

<wsdl:message name="AnfrageRisikoAnfrageL">
    <wsdl:part name="parameters" element="his1_0:typeIn"/>
</wsdl:message>
<wsdl:message name="AnfrageRisikoAntwortL">
    <wsdl:part name="parameters" element="his1_0:typeOut"/>
</wsdl:message>

folgt aus:

<wsdl:message name="AnfrageRisikoAnfrageL">
    <wsdl:part name="in" element="his1_0:typeIn"/>
</wsdl:message>
<wsdl:message name="AnfrageRisikoAntwortL">
    <wsdl:part name="out" element="his1_0:typeOut"/>
</wsdl:message>

Answer 3

@thehhv Lösung ist richtig. Es gibt Abhilfe, die Sie nicht benötigen xsds von Hand zu haben.

Gehen Sie zu Ihrem Dienst dann statt zu ?wsdl gehen gehen ?singleWsdl (Abbildung unten)

dann Seite als .wsdl Datei speichern (es wird bieten .svc es so aus)

dann offen Visual studio command prompt Sie es in (Win 7) Starten Sie finden können -> Alle Programme -> Visual Studio 2013 -> Visual Studio Tools -> VS2013 x64 native Tools-Eingabeaufforderung (etwas simmilar sein könnte)
Dann führen Sie den folgenden Befehl in Visual studio command prompt (wo anstelle von C: \ WebPricingService.wsdl ist, wo Sie Ihre WSDL-Datei gespeichert haben, es sei denn, es geschieht so, dass wir einander sehr ähnlich denken und wählen Sie denselben Dateinamen und den Ort, die besorgniserregend)

wsdl.exe C:\WebPricingService.wsdl

Es sollte Ihnen einige Warnungen geben, wie @thehhv sagt aber immer noch den Client in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs erzeugen (oder wo auch immer es setzt es auf Ihrem Rechner - Konsolenausgabe überprüfen, wo es ‚Writing Datei‘ liest)

Hope dies spart Ihnen einige Zeit.

Answer 4

In meinem Fall ist das Problem war anders, und ist gut beschrieben hier :

  

Jedes Mal, wenn der Name eines Teils ist „Parameter“ .Net angenommen doc / lit / gewickelt verwendet wird und erzeugt den Proxy entsprechend. Wenn auch wenn das Wort „Parameter“, um die WSDL-Datei verwendet wird, nicht doc / lit / umwickelt (wie im letzten Beispiel) .Net kann uns einige Fehler geben. Welche Fehler? Sie ahnen richtig: „Diese Elemente stammen, können nicht“. Jetzt können wir verstehen, was der Fehler bedeutet: NET versucht, das Stammelement wegzulassen, wie es doc denkt / lit / gewickelt verwendet wird. Jedoch kann dieses Element nicht entfernt werden, da es nicht Attrappe ist. - Es sollten aktiv durch den Nutzer aus wenigen abgeleiteten Typen ausgewählt werden

Das Update ist wie folgt und funktionierte perfekt für mich:

  

Die Art und Weise, es zu beheben offen ist die WSDL-Datei in einem Texteditor und ändern Sie die Teilnamen von "Parametern" "parameters1" . Nun wird .Net kenne einen doc / lit / bare Proxy zu generieren. Das bedeutet, eine neue Wrapper-Klasse als Root-Parameter in dem Proxy angezeigt. Dies ist zwar ein wenig langweiliger api sein kann, wird sich dies nicht auf dem Draht-Format beeinflussen und der Proxy ist vollständig kompatibel.

^{(Betonung von mir)}

Answer 5

Falls jemand diese Wand trifft, hier ist das, was der Fehler in meinem Fall verursacht:

Ich habe eine Operation:

<wsdl:operation name="FormatReport">
  <wsdl:documentation>Runs a report, which is returned as the response</wsdl:documentation>
  <wsdl:input message="FormatReportRequest" />
  <wsdl:output message="FormatReportResponse" />
</wsdl:operation>

, die nimmt einen Eingang:

<wsdl:message name="FormatReportRequest">
  <wsdl:part name="parameters" element="reporting:FormatReportInput" />
</wsdl:message>

und eine weitere Operation:

<wsdl:operation name="FormatReportAsync">
  <wsdl:documentation>Creates and submits an Async Report Job to be executed asynchronously by the Async Report Windows Service.</wsdl:documentation>
  <wsdl:input message="FormatReportAsyncRequest" />
  <wsdl:output message="FormatReportAsyncResponse" />
</wsdl:operation>

einen Eingang unter:

  <wsdl:message name="FormatReportAsyncRequest">
    <wsdl:part name="parameters" element="reporting:FormatReportInputAsync" />
  </wsdl:message>

Und die Eingabeelemente sind Instanzen von zwei Typen:

<xsd:element name="FormatReportInput" type="reporting:FormatReportInputType"/>
<xsd:element name="FormatReportInputAsync" type="reporting:FormatReportAsyncInputType"/>

Hier ist der Haken - die reporting:FormatReportAsyncInputType Typ (ergibt sich aus), um die reporting:FormatReportInputType Typ erstreckt. Das ist, was das Werkzeug zu verwirren scheint und bewirken, dass die „Diese Elemente nicht abgeleitet werden können.“ Error. Sie können in der akzeptierte Antwort, dass folgende teh Vorschlag umgehen.

Answer 6

Falls Sie tun dies mit UPS Versand Wsdl und Sie mögen Entwickler tauschen Urls prod, wenn Sie für verschiedene Regionen bauen (debug, Entwickler, prod) usw. würden Sie den Befehl unter einem vb oder C # erzeugen Datei aus dem Ship.wsdl und dann außer Kraft setzen Werte in diesem Fall Ship.vb Datei.

WSDL /Language:VB /out:"C:\wsdl\Ship.vb" "C:\wsdl\Ship.wsdl"  C:\wsdl\UPSSecurity.xsd  C:\wsdl\ShipWebServiceSchema.xsd  C:\wsdl\IFWS.xsd  C:\wsdl\common.xsd