wsdl.exe Erreur: Impossible d'importer la liaison '...' de namespace '...'

Question

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

Error: Unable to import binding 'SomeBinding' from namespace 'SomeNS'.

• Unable to import operation 'someOperation'.
• These members may not be derived.

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

Pour résumer, j'ai un WSDL valide, mais l'outil ne l'aime pas. Ce que je cherche, c'est si quelqu'un a beaucoup d'expérience avec l'outil wsdl.exe et connaît un secret gotcha que je n'ai pas.

Answer 1

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

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

a donné quelques avertissements WSDL mais il a fait créer une interface de service ok.

Answer 2

Parfois, vous devez changer votre code ur. les noms partiels message ne doit pas les mêmes;)

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

à cette:

<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

@thehhv solution est correcte. Il existe une solution de contournement qui ne vous oblige pas à ajouter xsd s à la main.

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

puis enregistrez la page sous forme de fichier .wsdl (il offrira .svc changer il)

puis ouvrez Visual studio command prompt vous pouvez le trouver dans (Win 7) Démarrer -> Tous les programmes -> Visual Studio 2013 -> Outils Visual Studio -> Invite de commandes VS2013 x64 Native Tools (pourrait être quelque chose simmilar)
Puis exécutez la commande suivante dans Visual studio command prompt (où à la place de C: \ WebPricingService.wsdl est l'endroit où vous avez enregistré votre wsdl, sauf si nous pensons que nous nous ressemblons beaucoup et choisissons le même nom de fichier et l'emplacement qui préoccupe)

wsdl.exe C:\WebPricingService.wsdl 

il devrait vous donner quelques avertissements comme @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 lit « fichier d'écriture »)

J'espère que cela vous évite moi.

Answer 4

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

Whenever the name of a part is "parameters" .Net assumed doc/lit/wrapped is used and generates the proxy accordingly. If even though the word "parameters" is used the wsdl is not doc/lit/wrapped (as in the last example) .Net may give us some error. Which error? You guessed correctly: "These members may not be derived". Now we can understand what the error means: .Net tries to omit the root element as it thinks doc/lit/wrapped is used. However this element cannot be removed since it is not dummy - it should be actively chosen by the user out of a few derived types.

Le correctif est la suivante, et a parfaitement fonctionné pour moi:

The way to fix it is open the wsdl in a text editor and change the part name from "parameters" to "parameters1". Now .Net will know to generate a doc/lit/bare proxy. This means a new wrapper class will appear as the root parameter in the proxy. While this may be a little more tedious api, this will not have any affect on the wire format and the proxy is fully interoperable.

^{(souligné par moi)}

Answer 5

Dans le cas où quelqu'un frappe ce mur, voici 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 une 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> 

prenant 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 type reporting:FormatReportAsyncInputType étend (dérive de) du type reporting:FormatReportInputType. C'est ce qui semble confondre l'outil et provoquer le "Ces membres ne peuvent pas être dérivés." Erreur. Vous pouvez contourner cela en suivant la suggestion dans la réponse acceptée.