Salut à tous,
 
Dans le cadre d'un développement à mon boulot, j'ai besoin de faire un programme en VB.NET invoquant un web service.
 
Etant novice en la matière, je me suis donc entraîné sur un service simple proposé par le site WebserviceX (en l'occurence un service qui renvoie la météo d'une ville passée en paramètre), j'ai utilisé l'assisant de Visual Studio, rentré l'url du service (un truc du genre "http://.../monService.asmx?wsdl" ) et choisi un nom (Disons "MonService" )
Ensuite j'ai pu facilement créer une instance de la classe MonService.LaClasseDuWebService.
Bref tout marche.
 
Le problème que je rencontre à présent est que j'ai voulu essayer le webservice dont j'ai réellement besoin.
Premier problème, l'url est de la forme "http://.../monService?wsdl", donc déjà sans le asmx.
Je lance l'assistant et rentre cette url, pas d'erreur, mais impossible d'instancier la classe dont j'ai besoin, elle est même absente de l'auto-completion.
 
Avez-vous déjà rencontré ce problème ? Si oui, pourriez-vous m'aider ?
 
Merci d'avance !
 

Je pars du principe que tu fais du WS "à l'ancienne", sans passer par WCF.
Comment ça ? Il te la génère bien ta classe ? Quand tu regardes le code il a la bonne tête (namespace, nom de classe) ?
 
Petite info : si plus tard tu dois gérer des trucs tels que pouvoir changer à la volée l'url d'accès à ton service (pour switcher entre recette et prod par exemple), tu seras confronté au limite de l'assistant de VS, pour générer ta classe proxy il faudra passer par un EXE fourni avec VS (wsdl.exe) qui s'utilise avec une tripotée de paramètres en ligne de commande.

Alors, j'ai suivi ton conseil et affiché tous les fichiers. A partir de la j'ai ajouté mes deux web services pour les comparer (celui qui donne la météo et celui sur lequel je suis sensé bosser).
En dépliant mes web services, je trouve effectivement un fichier "Reference.map" que je peux déplier à son tour, et je me suis aperçu que Visual m'avait généré une classe "Reference.vb", mais seulement pour le web service qui donne la météo... Du coup je comprends pourquoi mon service n'était pas présent dans l'auto-completion.
 
Est-ce du au fait que le service n'est pas développé en .NET du coté serveur ?
J'avais aussi oublié de préciser que je suis doit me connecter au web service avec un login et un mot de passe, est ce que ça pourrait être la raison du problème ?
Bref, est ce qu'il faut que j'utilise le service "à la main", sans passer par l'assistant VS ?

 
En fait, le login ne se fait pas en appelant des méthodes du web service, mais à mon avis il faut entrer les identifiants au moment où on ajoute le service au projet.
Du coup je pense que VS ne génère pas de namespace car il n'a pas accès aux méthodes puisque le service est signé.
Maintenant, où entrer ces identifiants, j'ai pas trouvé...
 
Edit : Comme l'a dit TotalRecall dans son message, je pense qu'il faut passer par l'executable wsdl.exe pour gérer plus de paramètres. (Il semblerait notamment qu'on puisse utiliser un champ identifiant et password). Du coup, je vais essayer et vous tiens au courant de mes avancées !  

Même pour afficher le WSDL tu as besoin de te logger ?
Pour moi le WSDL à lui seul suffit à générer les classes proxies, quelque soit la méthode d'authentification au service lui même.
Par contre c'est vrai que si la classe proxy ne prned pas en charge les contraintes d'authentification, là on risque d'avoir un problème à un moment donné .
Note qu'un fichier WSDL est un bête XML formaté spécifiquement, tu peux l'ouvrir directement dans ton navigateur. Essaye, tu verras si tu as une fenetre d'authentification qui s'ouvre.
Tu pourrais nous en donner l'url pour voir sa tête ou c'est confidentiel ?

Sinon tout ce que dit Fred82 est exact, c'est pour ça que moi aussi je t'invitais à jeter un oeil aux fichiers générés.

Fred > à propos de wsdl.exe, je citais les urls en exemple mais je crois qu'à l'époque j'avais une autre raison d'en passer par là pour contrôler finement le truc. Et puis si ton WS change toutes les semaines ça t'évite d'avoir à passer par l'assistant, tu mets la ligne de commande avec toutes les infos (url, namespace, paramètres à la con) dans un .bat et hop.
Ceci dit pour l'url ta remarque est parfaitement juste !

Par exemple en tapant WSDL dans google après quelques résultats il y avait celui là, un machin Amazon : http://webservices.amazon.com/AWSE [...] rvice.wsdl
Tu peux l'ouvrir directement.

Et pour info si tu n'as pas encore vu, un truc excellent avec .Net c'est qu'outre l'accès SOAP, quand tu crées un WS il te génère aussi des formulaires (ceux qui s'affichent quand tu appelles l'ASMX) qui te permette de simuler graphiquement des appels au WS.

(Je vois que tu éditais ton message en même temps que je postais les miens donc je refais un post pour m'assurer que tu as bien vu les deux miens précédents )

Alors après divers essais, je me suis aperçu que le fichier wsdl ne semblait pas tout à fait valide, en tout cas pas assez pour permettre la génération de code.
Quand j'essaie d'ajouter la référence web, j'obtiens cette erreur :  
"Erreur de l'outil personnalisé : Impossible d'importer WebService/Schéma. Impossible d'importer la liaison 'XXXX' à partir de l'espace de noms 'XXXX'. Impossible d'importer l'opération 'XXXX'. Le type de données 'XXXX' est manquant."
 
Par contre, je sais que le web service fonctionne quand même car d'autres personnes arrivent à l'utiliser. (Mais avec un programme Java)
Du coup, je pense que je vais devoir me taper le code à la main...
 
Pour l'url du wsdl, je préfère pas la mettre sur le topic pour des raisons que vous comprendrez, mais je peux éventuellement la passer en MP.

Envoyé à tous les deux !

Même avis que Fred82 pour ce qui est des spécificités Java.
 
Je ne m'amuse pas à lire des WSDL d'habitude mais j'essaye avec le tiens et j'ai l'impression qu'il y a juste la mention des méthodes du contrat, mais rien sur les types échangées.  
A la deuxième ligne il y a une référence import vers un autre WSDL qui lui définit les types (en supposant que je comprenne bien), il faut voir si les deux sont bien en cohérence entre eux...
 
Ton service a l'air simple, au pire tu pourrais peut être implémenter à la main les échanges ? (pas idéal du tout mais bon).
Si tu as l'équivalent en classes Java des objets transmis ça doit pouvoir s'adapter assez simplement.

Hello !
 
Alors je me suis décidé à me remettre sur cette histoire de web service, il semblerait que je doivent me coltiner le codage de ma classe proxy à la main.
 
J'ai donc écrit une petite classe en VB.NET :

Quand je l'utilise dans mon main, je tombe sur une erreur bizarre : "System.ArgumentException: Le nom de la méthode Web Service maMethode n'est pas valide"
Je pensais que le problème venait du service et j'ai été pris d'un gros doute : j'ai débranché mon cable ethernet et lancé l'application -> même erreur !  
 
J'ai eu beau chercher un peu partout, j'ai pas trouvé de personnes qui avaient la même erreur que moi... Vous auriez une idée ? (Je pense pas que le problème soit du à l'identification, car d'après la personne qui a écrit le service, je devrait avoir un code d'erreur différent dans ce cas)

J'ai essayé de renseigner ce paramètre, mais la réponse est toujours la même : "System.ArgumentException: Le nom de la méthode Web Service maMethode n'est pas valide"...
En fait je ne suis même pas sur de joindre correctement le service en question puisque lorsque je ne suis pas connecté, l'erreur est exactement la même. N'y a-t-il pas un moyen pour vérifier que l'on est bien connecté au service avant d'invoquer une méthode ?
 
En fait les seuls personnes qui utilisent ce service sont les personnes qui l'ont codé pour le moment et c'est le wsdl qui est généré à partir du code du service, donc je pense pas qu'ils aient besoin de générer du code.
Je suis à peu près sur que le WSDL n'est pas valide, mais je pense que c'est possible de le faire fonctionner tout de même, puisqu'ils y arrivent.

Et là il va entendre "En java" .

Je suis aussi d'avis de corriger le service et son wsdl. Si quelqu'un d'autre doit le consommer un jour il butera sur les mêmes galères, et puis je ne sais pas trop quelle latitude tu as pour bricoler tout ça mais à un moment ou un autre tu risques peut être de te faire taper sur les doigts si tu passes trop de temps à faire fonctionner le bousin...
En plus si ça se trouve un jour ils vont modifier quelques trucs et là tu pourras à nouveau t'amuser à adapter tt ça.
Si on a inventé des standards comme SOAP c'est précisément pour se brancher dessus en passant par des trucs éprouvés sans se prendre la tête, alors que là à cause de leurs erreurs tu dois réinventer la roue.
Du moins si on a bien compris la situation.

C'est clair, je te suis bien, mais au final se rapprocher d'eux ne fera sans doute que confirmer un truc qu'on sait déjà, sans apporter une solution au pb (si ce n'est en s'engageant à corriger), c'est ce que j'ai voulu dire. On est sur la même longueur d'onde je pense

Merci pour ce post ! J'avais déjà fait le même genre d'bservation mais j'imputais ça à mon manque de maitrise du sujet, à des spécificités de type et je n'imaginais pas que c'était à ce point ; le tableau est effectivement assez consternant ...