Encontramos la solución a este contratiempo, o por lo menos eso esperamos. Si presentas dudas deja tu comentario y sin pensarlo
Solución:
Me he encontrado con el mismo mensaje de error. Después de investigar por un tiempo, descubrí que uno puede proporcionar archivos xsd además del archivo wsdl. Así que se incluyeron/importaron archivos .xsd además de .wsdl al final del comando wsdl de la siguiente manera:
wsdl.exe miWebService.wsdl miXsd1.xsd miTipo1.xsd miXsd2.xsd …
Wsdl dio algunas advertencias pero creó una interfaz de servicio aceptable.
a veces tienes que cambiar tu código. los nombres de las partes del mensaje no deberían ser los mismos;)
a esto:
En mi caso el problema fue diferente, y está bien descrito aquí:
Cada vez que el nombre de una parte es “parámetros”, .Net supone que se usa doc/lit/wrapped y genera el proxy en consecuencia. Si a pesar de que se usa la palabra “parámetros”, el wsdl no está doc/lit/wrapped (como en el último ejemplo), .Net puede darnos algún error. ¿Qué error? Ha acertado: “Es posible que estos miembros no se deriven”. Ahora podemos entender lo que significa el error: .Net intenta omitir el elemento raíz porque cree que se usa doc/lit/wrapped. 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 contenedora como 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 del cable y el proxy es totalmente interoperable.
(énfasis mío)
Te mostramos reseñas y calificaciones
Puedes respaldar nuestro trabajo añadiendo un comentario y valorándolo te damos las gracias.