wsdl.exe Fehler: Kann nicht verbindlich ‚...‘ von Namensraum importieren ‚...‘

Question

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

Error: Unable to import binding 'SomeBinding' from namespace 'SomeNS'.

• Unable to import operation 'someOperation'.
• These members may not be derived.

Ich bin Ich benutze den Document-Literal-Stil, und nach meinem besten Wissen befolge 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 Tool wsdl.exe hat und weiß über einige geheime Gotcha, dass ich nicht weiß.

Answer 1

Ich bin auf die gleiche Fehlermeldung geraten. Nach dem Graben für eine Weile, fand heraus, dass man xsd-Dateien zusätzlich zur 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 müssen Sie Ihren 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> 

dazu:

<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 eine Problemumgehung, die es nicht erforderlich macht, xsd s manuell hinzuzufügen.

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

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

dann geöffnet Visual studio command prompt Sie können es finden in (Win 7) Start -> Alle Programme -> Visual Studio 2013 -> Visual Studio-Tools -> VS2013 x64 Native Tools Eingabeaufforderung (könnte etwas Ähnliches sein)
Dann 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 denselben Dateinamen und den Speicherort wählen, ist besorgniserregend) laufen

wsdl.exe C:\WebPricingService.wsdl 

es sollten Sie einige Warnungen geben, wie @thehhv sagte 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)

Hoffe, das spart dir etwas Ti mich.

Answer 4

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

Whenever the name of a part is "parameters" .Net assumed doc/lit/wrapped is used and generates the proxy accordingly. If even though the word "parameters" is used the wsdl is not doc/lit/wrapped (as in the last example) .Net may give us some error. Which error? You guessed correctly: "These members may not be derived". Now we can understand what the error means: .Net tries to omit the root element as it thinks doc/lit/wrapped is used. However this element cannot be removed since it is not dummy - it should be actively chosen by the user out of a few derived types.

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

The way to fix it is open the wsdl in a text editor and change the part name from "parameters" to "parameters1". Now .Net will know to generate a doc/lit/bare proxy. This means a new wrapper class will appear as the root parameter in the proxy. While this may be a little more tedious api, this will not have any affect on the wire format and the proxy is fully interoperable.

^{(Betonung von mir)}

Answer 5

Wenn jemand diese Wand trifft, ist hier, was den 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> 

, der einen Eingang nimmt:

<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> 

nimmt eine Eingabe:

<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 erstreckt (ergibt sich aus) die reporting:FormatReportInputType Typ. Das scheint das Werkzeug zu verwirren und zu bewirken, dass "diese Mitglieder nicht abgeleitet werden können". Error. Sie können das nach dem Vorschlag in der angenommenen Antwort umgehen.