wsdl.exe Error: Unable to import binding '...' from namespace '...'
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.
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>
<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>
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)