wsdl.exe Error: Unable to import binding '…' from namespace '…'

Question

When running wsdl.exe on a WSDL I created, I get this error:

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

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

I'm using the document-literal style, and to the best of my knowledge I'm following all the rules.

To sum it up, I have a valid WSDL, but the tool doesn't like it.

What I'm looking for is if someone has lots of experience with the wsdl.exe tool and knows about some secret gotcha that I don't.

Answer 1

I have came across to the same error message. After digging for a while, found out that one can supply xsd files in addition to wsdl file. So included/imported .xsd files in addition to .wsdl at the end of the wsdl command as follows:

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

Wsdl gave some warnings but it did create an ok service interface.

Answer 2

sometimes u have to change ur code. the message part-names should not the same ;)

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

to this:

<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 solution is correct. There's workaround that does not require you to add xsds by hand.

Go to your service then instead of going ?wsdl go to ?singleWsdl (screenshot below)

then save page as .wsdl file (it will offer .svc so change it)

then open Visual studio command prompt you can find it in (Win 7) Start -> All Programs -> Visual studio 2013 -> Visual Studio tools -> VS2013 x64 Native Tools Command Prompt (could be something simmilar)
Then run the following command in Visual studio command prompt (where instead of C:\WebPricingService.wsdl is where you have saved your wsdl, unless it so happens that we think very much alike and choose same file name and location which is worrying)

wsdl.exe C:\WebPricingService.wsdl

It should give you some warnings as @thehhv said but still generate the client in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs (or wherever it puts it on your machine - check console output where it reads 'Writing file')

Hope this saves you some time.

Answer 4

In my case the problem was different, and is well described here:

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.

The fix is as follows, and worked perfectly for me:

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.

^{(emphasis by me)}

Answer 5

In case someone hits this wall, here is what caused the error in my case:

I have an 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>

which takes an input:

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

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

taking an input:

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

And the input elements are instances of two types:

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

Here is the catch - the reporting:FormatReportAsyncInputType type extends (derives from) the reporting:FormatReportInputType type. That's what seems to confuse the tool and cause the "These members may not be derived." error. You can go around that following teh suggestion in the accepted answer.

Answer 6

In case you are doing this with UPS Shipping wsdl and you want to swap dev to prod urls when you are building for different regions (debug,dev,prod) etc. You would use the command below to generate a vb or C# file from the Ship.wsdl and then override values in this case Ship.vb file.

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