Erro wsdl.exe:Não é possível importar a ligação '…' do namespace '…'
Pergunta
Ao executar wsdl.exe em um WSDL que criei, recebo este erro:
Erro:Não é possível importar a ligação 'SomeBinding' do namespace 'SomeNS'.
- Não foi possível importar a operação 'someOperation'.
- Esses membros não podem ser derivados.
Estou usando o estilo document-literal e, até onde sei, estou seguindo todas as regras.
Resumindo, tenho um WSDL válido, mas a ferramenta não gosta dele.
O que estou procurando é se alguém tiver muita experiência com a ferramenta wsdl.exe e souber de alguma pegadinha secreta que eu não conheço.
Solução
Me deparei com a mesma mensagem de erro.Depois de pesquisar um pouco, descobri que é possível fornecer arquivos xsd além do arquivo wsdl.Portanto, incluímos/importamos arquivos .xsd além de .wsdl no final do comando wsdl da seguinte maneira:
wsdl.exe meuWebService.wsdl meuXsd1.xsd meuTipo1.xsd meuXsd2.xsd ...
O Wsdl deu alguns avisos, mas criou uma interface de serviço ok.
Outras dicas
às vezes você tem que alterar seu código.os nomes das partes da mensagem não devem ser os mesmos;)
<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>
para isso:
<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>
A solução @thehhv está correta.Há uma solução alternativa que não exige que você adicione xsd
é à mão.
Vá para o seu serviço então em vez de ir ?wsdl
Vá para ?singleWsdl
(captura de tela abaixo)
então salve a página como .wsdl
arquivo (ele oferecerá .svc
então mude)
então abra Visual studio command prompt
você pode encontrá-lo em (Win 7) Iniciar -> Todos os Programas -> Visual Studio 2013 -> Ferramentas do Visual Studio -> Prompt de Comando das Ferramentas Nativas do VS2013 x64 (pode ser algo semelhante)
Em seguida, execute o seguinte comando em Visual studio command prompt
(onde em vez de C:\WebPricingService.wsdl é onde você salvou seu wsdl, a menos que pensemos muito da mesma forma e escolhamos o mesmo nome de arquivo e local que é preocupante)
wsdl.exe C:\WebPricingService.wsdl
Deve dar alguns avisos como @thehhv disse, mas ainda assim gerar o cliente em C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs
(ou onde quer que ele esteja em sua máquina - verifique a saída do console onde se lê 'Escrevendo arquivo')
Espero que isso economize algum tempo.
No meu caso o problema era diferente e está bem descrito aqui:
Sempre que o nome de uma parte for "parâmetros", o .Net assume que doc/lit/wrapped é usado e gera o proxy de acordo.Se mesmo que a palavra "parâmetros" seja usada o wsdl não for doc/lit/wrapped (como no último exemplo) o .Net pode nos dar algum erro.Qual erro?Você adivinhou corretamente:“Esses membros não podem ser derivados”.Agora podemos entender o que o erro significa:.Net tenta omitir o elemento raiz porque pensa que doc/lit/wrapped é usado.No entanto, este elemento não pode ser removido, pois não é fictício - deve ser escolhido ativamente pelo usuário dentre alguns tipos derivados.
A correção é a seguinte e funcionou perfeitamente para mim:
A maneira de consertar é abrir o wsdl em um editor de texto e alterar o nome da peça de "parâmetros" para "parâmetros1".Agora o .Net saberá como gerar um proxy doc/lit/bare.Isso significa que uma nova classe wrapper aparecerá como parâmetro raiz no proxy.Embora isso possa ser uma API um pouco mais tediosa, isso não afetará o formato da ligação e o proxy é totalmente interoperável.
(ênfase minha)
Caso alguém bata nesta parede, aqui está o que causou o erro no meu caso:
Eu tenho uma operação:
<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 recebe uma entrada:
<wsdl:message name="FormatReportRequest">
<wsdl:part name="parameters" element="reporting:FormatReportInput" />
</wsdl:message>
e outra operação:
<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>
recebendo uma entrada:
<wsdl:message name="FormatReportAsyncRequest">
<wsdl:part name="parameters" element="reporting:FormatReportInputAsync" />
</wsdl:message>
E os elementos de entrada são instâncias de dois tipos:
<xsd:element name="FormatReportInput" type="reporting:FormatReportInputType"/>
<xsd:element name="FormatReportInputAsync" type="reporting:FormatReportAsyncInputType"/>
Aqui está o problema - o reporting:FormatReportAsyncInputType
tipo estende (deriva de) o reporting:FormatReportInputType
tipo.É isso que parece confundir a ferramenta e causar "esses membros podem não ser derivados". erro.Você pode contornar isso seguindo a sugestão na resposta aceita.
Caso você esteja fazendo isso com o UPS Shipping wsdl e queira trocar URLs dev para prod quando estiver construindo para diferentes regiões (debug,dev,prod) etc.Você usaria o comando abaixo para gerar um arquivo vb ou C# a partir do Ship.wsdl e, em seguida, substituir os valores, neste caso, do arquivo 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