error wsdl.exe: No se puede importar de unión '...' de espacio de nombres '...'

Question

Cuando se ejecuta en un WSDL wsdl.exe creé, me sale este error:

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

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

estoy usando el estilo document-literal, y según mi leal saber y entender, estoy siguiendo todas las reglas.

Para resumir, tengo un WSDL válido, pero a la herramienta no le gusta.

Lo que estoy buscando es si alguien tiene mucha experiencia con la herramienta wsdl.exe y sabe algo de secretos que yo no conozco.

Answer 1

Me he encontrado con el mismo mensaje de error. Después de cavar por un tiempo, descubrió que uno puede suministrar archivos xsd además del archivo wsdl. Así incluidos importados .xsd archivos/además de .wsdl al final del comando WSDL de la siguiente manera:

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

Wsdl dio algunas advertencias pero sí crear una interfaz de servicio aceptable.

Answer 2

a veces tienes que cambiar tu código. los mensajes parciales de nombres no caso de un mismo;)

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

a esto:

<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 solución es correcta. Hay una solución que no requiere que agregue xsd s a mano.

Vaya a su servicio, entonces en vez de ir ?wsdl ir a ?singleWsdl (imagen abajo)

continuación, guardar la página como .wsdl archivo (que ofrecerá .svc por lo cambiarlo)

luego abrir Visual studio command prompt lo puedes encontrar en (Win 7) Inicio -> Todos los programas -> Visual Studio 2013 -> Herramientas de Visual Studio -> VS2013 x64 Native Tools Símbolo del sistema (podría ser algo similar)
A continuación, ejecute el siguiente comando en Visual studio command prompt (donde en lugar de C: \ WebPricingService.wsdl es donde se ha guardado el WSDL, a menos que se da la circunstancia de que pensamos muy parecidos y elija mismo nombre de archivo y la ubicación que es preocupante)

wsdl.exe C:\WebPricingService.wsdl 

se le debe dar algunas advertencias como @thehhv dijo, pero aun así generar el cliente en C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs (o donde se pone en su máquina - compruebe la salida de la consola donde se lee 'archivo de escritura')

Espero que esto te ahorre un poco yo.

Answer 4

En mi caso, el problema era diferente, y está bien descrito 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.

La solución es la siguiente, y funcionó a la perfección para mí:

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.

^{(énfasis por mí)}

Answer 5

En caso de que alguien llegue a este muro, aquí está lo que causó el error en mi caso:

tengo una operación:

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

que toma una entrada:

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

y otra operación:

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

teniendo una entrada:

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

y los elementos de entrada son ejemplos de dos tipos:

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

Aquí es la captura - el tipo reporting:FormatReportAsyncInputType se extiende (se deriva de) el tipo reporting:FormatReportInputType. Eso es lo que parece confundir a la herramienta y causar el "Estos miembros no pueden derivarse". error. Puede ir por ahí siguiendo la sugerencia en la respuesta aceptada.