Errore wsdl.exe:Impossibile importare l'associazione '...' dallo spazio dei nomi '...'

Question

Quando eseguo wsdl.exe su un WSDL che ho creato, ottengo questo errore:

Errore:Impossibile importare l'associazione "SomeBinding" dallo spazio dei nomi "SomeNS".

• Impossibile importare l'operazione "someOperation".
• Questi membri potrebbero non essere derivati.

Sto utilizzando lo stile letterale del documento e, per quanto ne so, sto seguendo tutte le regole.

Per riassumere, ho un WSDL valido, ma allo strumento non piace.

Quello che sto cercando è se qualcuno ha molta esperienza con lo strumento wsdl.exe e conosce alcuni trucchi segreti che io non conosco.

Answer 1

Mi sono imbattuto nello stesso messaggio di errore.Dopo aver scavato per un po', ho scoperto che è possibile fornire file xsd oltre al file wsdl.Quindi inclusi/importati i file .xsd oltre a .wsdl alla fine del comando wsdl come segue:

wsdl.exe mioWebService.wsdl mioXsd1.xsd mioTipo1.xsd mioXsd2.xsd ...

Wsdl ha fornito alcuni avvisi ma ha creato un'interfaccia di servizio ok.

Answer 2

a volte devi cambiare il tuo codice.i nomi delle parti del messaggio non dovrebbero essere gli stessi ;)

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

<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

La soluzione @thehhv è corretta.Esiste una soluzione alternativa che non richiede l'aggiunta xsdè a mano.

Vai al tuo servizio allora invece di andare ?wsdl vai a ?singleWsdl (schermata sotto)

quindi salva la pagina con nome .wsdl file (offrirà .svc quindi cambialo)

quindi aperto Visual studio command prompt puoi trovarlo in (Win 7) Start -> Tutti i programmi -> Visual studio 2013 -> Strumenti di Visual Studio -> Prompt dei comandi degli strumenti nativi VS2013 x64 (potrebbe essere qualcosa di simile)
Quindi esegui il seguente comando Visual studio command prompt (dove invece di C:\WebPricingService.wsdl è dove hai salvato il tuo wsdl, a meno che non accada che la pensiamo in modo molto simile e scegliamo lo stesso nome file e la stessa posizione, il che è preoccupante)

wsdl.exe C:\WebPricingService.wsdl

Dovrebbe darti alcuni avvisi come ha detto @thehhv ma generare comunque il client C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs (o ovunque lo inserisca sul tuo computer: controlla l'output della console dove si legge "Scrittura file")

Spero che questo ti faccia risparmiare un po' di tempo.

Answer 4

Nel mio caso il problema era diverso ed è ben descritto Qui:

Ogni volta che il nome di una parte è "parametri", .Net presuppone che venga utilizzato doc/lit/wrapped e genera il proxy di conseguenza.Se anche se viene utilizzata la parola "parametri", wsdl non è doc/lit/wrapped (come nell'ultimo esempio) .Net potrebbe darci qualche errore.Quale errore?Hai indovinato correttamente:"Questi membri potrebbero non essere derivati".Ora possiamo capire cosa significa l'errore:.Net tenta di omettere l'elemento root poiché ritiene che venga utilizzato doc/lit/wrapped.Tuttavia questo elemento non può essere rimosso poiché non è fittizio: dovrebbe essere scelto attivamente dall'utente tra alcuni tipi derivati.

La soluzione è la seguente e ha funzionato perfettamente per me:

Il modo per risolverlo è aprire wsdl in un editor di testo e modificare il nome della parte da "parametri" A "parametri1".Ora .Net saprà generare un proxy doc/lit/bare.Ciò significa che una nuova classe wrapper apparirà come parametro root nel proxy.Anche se questo potrebbe essere un po' più noioso dell'API, ciò non avrà alcun effetto sul formato del cavo e il proxy è completamente interoperabile.

^{(enfasi mia)}

Answer 5

Nel caso in cui qualcuno colpisca questo muro, ecco cosa ha causato l'errore nel mio caso:

Ho un'operazione:

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

che richiede un input:

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

e un'altra operazione:

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

prendendo un input:

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

E gli elementi di input sono istanze di due tipi:

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

Ecco il problema: il reporting:FormatReportAsyncInputType type estende (deriva da) the reporting:FormatReportInputType tipo.Questo è ciò che sembra confondere lo strumento e causare "questi membri potrebbero non essere derivati". errore.Puoi aggirare il problema seguendo il suggerimento nella risposta accettata.

Answer 6

Nel caso in cui lo stai facendo con UPS Shipping wsdl e desideri scambiare gli URL da dev a prod quando stai creando per regioni diverse (debug, dev, prod) ecc.Dovresti utilizzare il comando seguente per generare un file vb o C# da Ship.wsdl e quindi sovrascrivere i valori in questo caso il file 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