web-development-kb-es.site

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

Cuando ejecuto 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 de documento literal, y que yo sepa, 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 de algún secreto que no tengo.

.netsoapwsdl
31
Glenn Moss

Me encontré con el mismo mensaje de error. Después de excavar por un tiempo, descubrió que uno puede suministrar archivos xsd además del archivo wsdl. Así incluidos/importados 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.

51
thehhv

a veces tienes que cambiar tu código. los nombres de las partes 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>
8
mo.

La solución @thehhv es correcta. Hay una solución alternativa que no requiere que agregue xsds a mano.

Vaya a su servicio y luego en lugar de ir ?wsdl Vaya a ?singleWsdl (Captura de pantalla a continuación)

enter image description here

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

luego abra Visual studio command Prompt puede encontrarlo en (Win 7) Inicio -> Todos los programas -> Visual studio 2013 -> Visual Studio tools -> VS2013 x64 Native Tools Command Prompt (podría ser algo similar)
Luego ejecute el siguiente comando en Visual studio command Prompt (Donde en lugar de C:\WebPricingService.wsdl es donde ha guardado su wsdl, a menos que ocurra 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 aún generar el cliente en C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64\WebPricingService.cs (o donde sea que lo ponga en su máquina - verifique la salida de la consola donde se lee 'Escribiendo archivo')

enter image description here

Espero que esto te ahorre algo de tiempo.

4
Matas Vaitkevicius

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

Siempre que el nombre de una parte sea "parámetros" .Net asumió que se usa doc/lit/wrap y genera el proxy en consecuencia. Si a pesar de que se usan los "parámetros" de Word, wsdl no es doc/lit/wrap (como en el último ejemplo) .Net puede darnos algún error. Cual error Has adivinado correctamente: "Estos miembros no pueden derivarse". Ahora podemos entender lo que significa el error: .Net intenta omitir el elemento raíz ya que cree que se usa doc/lit/wrap. Sin embargo, este elemento no se puede eliminar ya que no es ficticio: el usuario debe elegirlo activamente entre algunos tipos derivados.

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

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

(énfasis por mí)

3
BartoszKP

En caso de que esté haciendo esto con UPS Shipping wsdl y quiera intercambiar dev a prod urls cuando esté compilando para diferentes regiones (depuración, dev, prod), etc. Utilizaría el siguiente comando para generar un archivo vb o C # desde Ship.wsdl y luego anula los valores en este caso el archivo Ship.vb.

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

En caso de que alguien golpee este muro, esto es lo que causó el error en mi caso:

Tengo una operacion:

<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 extiende (deriva de) el reporting:FormatReportInputType tipo. Eso es lo que parece confundir la herramienta y provocar el "No se pueden derivar estos miembros". error. Puede seguir esa siguiente sugerencia en la respuesta aceptada.

0
Alex Sk