.net - online - wsdl soap example

Error wsdl.exe: no se puede importar el enlace ''...'' desde el espacio de nombres ''...''

Question

Al ejecutar wsdl.exe en un WSDL que creé, aparece este error:

Error: no se puede importar el enlace ''SomeBinding'' del espacio de nombres ''SomeNS''.

• No se puede importar la operación ''someOperation''.
• Estos miembros no pueden ser derivados.

Estoy usando el estilo literal del documento, y a 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 que alguien tenga mucha experiencia con la herramienta wsdl.exe y sepa algo de secretos que yo no conozco.

Answer 1

@thehhv la solución es correcta. Hay una solución que no requiere que agregue xsd s a mano.

Vaya a su servicio en lugar de ir a ?singleWsdl ir a ?singleWsdl (captura de pantalla a continuación)

luego guarda la página como archivo .wsdl (ofrecerá .svc así que .svc )

a continuación, abra el Visual studio command prompt , puede encontrarlo en (Win 7) Inicio -> Todos los programas -> Visual Studio 2013 -> Herramientas de Visual Studio -> VS2013 x64 Native Tools Command Prompt (podría ser algo similar)
A continuación, ejecute el siguiente comando en el Visual studio command prompt (donde en lugar de C: / WebPricingService.wsdl es donde ha guardado su wsdl, a menos que suceda que pensamos mucho y elegimos el mismo nombre de archivo y ubicación que es preocupante)

wsdl.exe C:/WebPricingService.wsdl

Debería darle algunas advertencias como dijo @thehhv, pero generar el cliente en C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/WebPricingService.cs (o donde lo C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/WebPricingService.cs en su máquina - verificar salida de consola donde dice ''Escribir archivo'')

Espero que esto te ahorre algo de tiempo.

Answer 2

En caso de que alguien golpee esta pared, 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>

tomando una entrada:

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

Y los elementos de entrada son instancias de dos tipos:

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

Aquí está el truco: el reporting:FormatReportAsyncInputType tipo reporting:FormatReportAsyncInputType amplía (deriva de) el reporting:FormatReportInputType 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.

Answer 3

En mi caso, el problema era diferente, y está bien descrito here :

Siempre que el nombre de una parte sea "parámetros" .Net supone que se usa doc / lit / wrapped y genera el proxy en consecuencia. Si a pesar de que se utiliza la palabra "parámetros", wsdl no es doc / lit / wrapped (como en el último ejemplo) .Net puede darnos algún error. ¿Qué error? Adivinaste correctamente: "Es posible que estos miembros no se deriven". Ahora podemos entender lo que significa el error: .Net intenta omitir el elemento raíz porque piensa que se usa doc / lit / wrapped. Sin embargo, este elemento no puede eliminarse, ya que no es ficticio; el usuario debe elegirlo activamente de entre algunos tipos derivados.

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

La forma de solucionarlo es abrir el archivo wsdl en un editor de texto y cambiar el nombre de la pieza de "parámetros" a "parámetros1" . Ahora .Net sabrá generar un proxy doc / lit / bare. Esto significa que aparecerá una nueva clase contenedora como el parámetro raíz en el proxy. Si bien esto puede ser una API un poco más tediosa, esto no tendrá ningún efecto en el formato de conexión y el proxy es completamente interoperable.

^{(énfasis por mí)}

Answer 4

Me encontré 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. Por lo tanto, se incluyeron / importaron archivos .xsd 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 creó una interfaz de servicio aceptable.

Answer 5

a veces tienes que cambiar tu código. los nombres de parte del mensaje no deberían ser iguales;)

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