wsdl.exe Erreur: Impossible d'importer de liaison " ... " à partir de l'espace de noms '...'

Lors de l'exécution de wsdl.exe sur un WSDL j'ai créé, j'ai cette erreur:

Erreur: Impossible d'importer de liaison "SomeBinding' de l'espace de noms 'SomeNS'.

Impossible d'importer de l'opération "someOperation'.

Ces membres ne peuvent pas être dérivées.

Je suis en utilisant le document-style littéral, et au meilleur de ma connaissance que je suis en suivant toutes les règles.

Pour résumer, j'ai un valide WSDL, mais l'outil ne l'aime pas.

Ce que je cherche si quelqu'un qui a beaucoup d'expérience avec le wsdl.exe outil et connaît les secrets de gotcha que je n'ai pas.

Jetez un oeil à cet article.

InformationsquelleAutor Glenn Moss | 2008-09-16

49

Je suis tombé sur le même message d'erreur. Après avoir creusé pendant un certain temps, que l'on peut fournir les fichiers xsd en plus du fichier wsdl. Ainsi inclus/importés .les fichiers xsd en plus .wsdl à la fin de l'wsdl commande comme suit:

wsdl.exe myWebService.wsdl myXsd1.xsd myType1.xsd myXsd2.xsd ...

Wsdl a donné quelques mises en garde, mais elle a créé un ok interface de service.

InformationsquelleAutor thehhv

parfois u pour changer ur de code.
la partie du message-les noms ne sont pas la même chose 😉

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

à ceci:

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

C'était mon cas. Je vous remercie.

InformationsquelleAutor mo.

4

@thehhv la solution est correcte. Il y a solution de contournement qui ne nécessite pas l'ajout d' xsds à la main.

Allez à votre service, au lieu d'aller ?wsdl aller à ?singleWsdl (capture d'écran ci-dessous)

puis enregistrez la page en tant que .wsdl fichier (il offrira .svc donc le changer)

puis ouvrez Visual studio command prompt vous pouvez le trouver dans (Win 7) Démarrer -> Tous les Programmes -> Visual studio 2013 -> outils de Visual Studio -> VS2013 x64 Natif Invite de Commande des Outils (peut-être pour quelque chose simmilar)

Ensuite, exécutez la commande suivante dans Visual studio command prompt (où, au lieu de C:\WebPricingService.wsdl est l'endroit où vous avez enregistré votre fichier wsdl, sauf s'il se trouve que nous pensons très semblables, et de choisir le même nom de fichier et l'emplacement de ce qui est inquiétant)
```
wsdl.exe C:\WebPricingService.wsdl
```
Il devrait vous donner quelques avertissements que @thehhv dit, mais encore générer le client dans C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\WebPricingService.cs (ou partout où il le met sur votre machine - vérifier la sortie de la console où il écrit "de l'Écriture du fichier')

Espère que cela vous fait gagner du temps.

InformationsquelleAutor Matas Vaitkevicius
3

Dans mon cas, le problème était différent, et il est bien décrit ici:

Chaque fois que le nom d'une partie "paramètres" .Net supposé doc/lit/enveloppé est utilisé et génère le proxy en conséquence. Si bien que le mot "paramètres" est utilisé, le wsdl n'est pas doc/lit/emballé (comme dans le dernier exemple) .Net peut nous donner une certaine erreur. Quelle erreur? Vous avez bien deviné: "Ces membres ne peuvent pas être dérivées". Maintenant, nous pouvons comprendre ce que l'erreur signifie: .Net essaie d'omettre l'élément racine car il pense que doc/lit/enveloppé est utilisé. Toutefois, cet élément ne peut pas être supprimée car elle n'est pas factice - il doit être choisi par l'utilisateur à partir de quelques types dérivés.

Le fixer comme suit, et a parfaitement fonctionné pour moi:

Le moyen pour résoudre ce problème est d'ouvrir le document wsdl dans un éditeur de texte et modifiez le nom de la pièce de "paramètres" à "parameters1". Maintenant .Net saura générer une doc/lit/nue-proxy. Cela signifie une nouvelle classe wrapper apparaît comme le paramètre root dans le proxy. C'est peut-être un peu plus fastidieux api, cela n'aura aucune incidence sur le format de câble et le proxy est entièrement interopérable.

^{(accent mis par moi)}
- Bonne explication, ne peut pas croire que c'est ma première fois rencontré ce problème après de nombreuses années de développement.
InformationsquelleAutor BartoszKP

Au cas où quelqu'un frappe de ce mur, ici, c'est ce qui a causé l'erreur dans mon cas:

J'ai une opération:

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

qui prend en entrée:

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

et une autre opération:

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

de prendre une entrée:

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

Et les éléments d'entrée sont des instances de deux types:

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

Voici les captures - le reporting:FormatReportAsyncInputType type s'étend (dérive) le reporting:FormatReportInputType type. C'est ce que semble confondre l'outil et la cause de la "Ces membres ne peuvent pas être dérivées." erreur. Vous pouvez faire le tour qu'à la suite de la suggestion dans l'acceptation de réponse.

InformationsquelleAutor Alex Sk

0

Dans le cas où vous faites cela avec UPS Livraison wsdl et vous souhaitez changer de dev de prod url lorsque vous avez des capacités pour les différentes régions (debug,dev,prod) etc. Vous pouvez utiliser la commande ci-dessous pour générer un vb ou C# de fichier à partir du Navire.wsdl et ensuite de remplacer des valeurs dans ce cas Navire.vb fichier.
```
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
```
InformationsquelleAutor user2242618

Vous devez vous connecter pour publier un commentaire.