Erreur de référence de service: impossible de générer le code pour la référence de service

J'ai une solution de service Windows et j'essaie d'ajouter une référence de service à un service Web Hermes (serveur de messages ebms OpenSource) dans VS2010.

Je peux trouver le service Web à l'aide de son URL, mais lorsque j'essaie de remplir la référence de service, j'obtiens les erreurs suivantes dans Visual Studio:

Error 8 Custom tool error: Failed to generate code for the service reference 'testService'.  Please check other error and warning messages for details. C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler


Warning 6 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[@name='EbmsStatusQuery']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[@name='EbmsSoapHttpStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Warning 7 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[@name='EbmsSoapHttpStatusQuery']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:service[@name='EbmsMessageStatusQuery']/wsdl:port[@name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Warning 5 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://service.ebms.edi.cecid.hku.hk/' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[@name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Certaines recherches semblent suggérer que svcutil.exe n'a pas été en mesure de créer les proxys en raison de l'absence d'autorisations sur un répertoire (peut-être c: \ windows \ temp). J'ai essayé d'attribuer diverses autorisations d'accès, mais je ne sais pas vraiment quel utilisateur a besoin de l'autorisation ou s'il ne s'agit que d'un hareng rouge.

Toutes les idées seraient grandement appréciées.

Merci

Doit décocher les types de réutilisation dans tous les assemblys référencés de l'option Configurer la référence de service

Vérifiez ceci pour plus de détails

Faites un clic droit sur votre référence de service et choisissez Configure Service Reference...

Puis décochez Reuse types in referenced assemblies

Cliquez OK, nettoyez et reconstruisez votre solution.

J'ai également rencontré une erreur similaire lors de la tentative de génération du client pour un service Web à partir d'un projet ASP .Net MVC 4.0 à l'aide de Visual Studio 2012.

La racine du problème semble être le fait que le projet à partir duquel j'essayais de générer le client faisait référence à un assembly qui à son tour dépendait d'un autre assembly qui n'était pas référencé également.

Lorsque «Réutiliser les types dans les assemblys référencés» est activé dans la configuration du service, le générateur de service inspecte probablement tous les assemblys référencés pour obtenir une liste des types qui peuvent être réutilisés. Le fait que l'un des assemblys référencés fasse référence à un autre assemblage qui n'est pas disponible provoque probablement l'échec du générateur.

Décocher "Réutiliser les types dans les assemblys référencés" dans les configurations de service résoudra le problème ci-dessus , mais il y a un effet secondaire. L'option de réutilisation des types est là pour une raison et dans certains cas, elle évite la conversion inutile dans le code consommant le service.

Par exemple, si le service lui-même est généré à l'aide de WCF et que certains paramètres de méthodes à l'intérieur sont de type System.Guid, ils seront traduits en chaînes dans le client généré si l'option de réutilisation des types est désactivée.

Une alternative que je préfère à la désactivation de la réutilisation des types consiste à ajouter la référence de service du projet de bibliothèque de classes spécialement créé à cet effet. La seule chose à garder à l'esprit est de copier toutes les configurations liées au service depuis app.config de la bibliothèque de classes dans le fichier de configuration du projet de démarrage.

S'il existe des types définis dans des assemblys locaux qui doivent être réutilisés dans le client de service, ces assemblys doivent simplement être référencés à partir du projet de bibliothèque de classes mentionné ci-dessus, avec toutes leurs dépendances.

http://uliasz.com/2011/06/wcf-custom-tool-error-failed-to-generate-code-for-the-service-reference/#comment-1647

Merci à l'article ci-dessus.

Dans mon cas, j'ai ce problème avec mon projet WPF dans VS.Net 2008. Après avoir parcouru cet article, je me suis rendu compte que l'assembly utilisé dans le service Web est une version différente de l'assembly utilisée sur le client.

Cela fonctionne très bien après la mise à jour de l'assembly sur le client.

Il serait extrêmement difficile de deviner le problème car il est dû à une erreur dans le WSDL et sans examiner le WSDL, je ne peux pas en dire plus. Donc, si vous pouvez partager votre WSDL, faites-le.

Tout ce que je peux dire, c'est qu'il semble y avoir un schéma manquant dans le WSDL (avec l'espace de noms cible 'http://service.ebms.edi.cecid.hku.hk/'). Je connais les problèmes et la gestion différente du schéma lorsque les instructions d'inclusion sont ignorées.

En général, j'ai trouvé l'implémentation des services Web par Microsoft plutôt bonne, donc je pense que le service Web renvoie des WSDL douteux.

J'obtiens la même erreur dans Silverlight 5 (VS2012)

Vous pouvez également supprimer les références à:

• System.ServiceModel.DomainServices.Client
• System.ServiceModel.DomainServices.Client.Web

Après avoir mis à jour les références de service, assurez-vous de les rajouter.

Comme indiqué ci-dessus, plusieurs problèmes sont possibles. Ce que nous avons constaté, c'est que le .DLL pour la bibliothèque WCF avait été ajouté en tant que référence au projet client. Ceci, à son tour, a créé des problèmes avec la résolution des objets et a donc provoqué le «vidage» des fichiers par les étapes de génération de code. Bien que décocher l'utilisation "Réutiliser les types ..." peut sembler être une réponse, cela crée des définitions supplémentaires de types d'objets, qui sont des proxies des types réels, dans un nouvel espace de nom, ce qui provoque alors toutes sortes de problèmes de "compatibilité" avec l'utilisation de ces types. Ce n'est que si vous voulez vraiment "cacher" un type que vous devez cocher cette option.

Cacher le type serait approprié lorsque vous ne voulez pas qu'une dépendance de type «DLL» «fuit» dans un projet que vous essayez de garder séparé d'un autre. Si la DLL pour le projet de bibliothèque WCF s'insinue dans les références de projet client, vous rencontrerez ce problème avec toutes sortes d'effets secondaires étranges puisque les définitions de type se trouvent également dans la DLL.

faire face au même problème, résolu en exécutant Visual Studio en mode administrateur

J'ai rencontré ce problème lors de la mise à niveau d'une solution VS2010 WCF + Silverlight dans VS2015 Professional . Outre la mise à niveau automatique de Silverlight 4 vers Silverlight 5, la valeur de la case à cocher de réutilisation des références de service a été modifiée et la génération a échoué.

"Réutiliser les types" n'est pas toujours le problème lorsque cette erreur se produit.

Lors de l'ajout d'une référence à un service plus ancien, cliquez sur «avancé» puis sur «Ajouter une référence Web». Maintenant, connectez-vous à votre wsdl et tout devrait fonctionner.

Si vous souhaitez corriger cela sans décocher la case à cocher de réutilisation de l'assemblage, voici ce qui a fonctionné pour moi:

• Supprimer l'assembly référencé que vous souhaitez réutiliser
• Supprimer tout le dossier bin du projet
• Mettre à jour la référence du service
  • Conserver "Réutiliser les types dans les assemblys référencés spécifiés"
• Ajoutez à nouveau une référence à l'assemblage pour corriger les erreurs
• Mettre à jour à nouveau la référence du service

Le redémarrage de Visual Studio a fait l'affaire pour moi. J'utilise VS 2015.

J'ai eu ce problème en essayant de mettre à jour ma référence de service (l'erreur n'apparaît que lors de l'ajout d'une référence de service) mais je ne voulais pas supprimer la case à cocher de réutilisation de l'assemblage.

Ce qui a fonctionné pour moi était le suivant:

• Supprimer l'assembly référencé que je souhaitais réutiliser
• Mettre à jour la référence du service
• Conserver "Réutiliser les types dans les assemblys référencés spécifiés"
• Ignorez les erreurs, c'est parce que la référence est manquante!
• Ajoutez à nouveau une référence à l'assemblage pour corriger les erreurs
• Mettre à jour à nouveau la référence du service

Voila, maintenant il se met à jour et n'essaye plus de supprimer tout mon code généré.

J'étais presque prêt à abandonner la fonctionnalité des types de réutilisation ...

EDIT: assurez-vous également que la configuration de construction est AnyCPU ou x86, car svcutil est bogué avec x64.

À l'électeur défavorable: Désolé si cela n'a pas fonctionné pour vous, je ne sais même pas pourquoi cela a fonctionné pour moi, mais cela a fonctionné. J'ai peut-être fait autre chose cette fois qui a résolu le problème, mais aucun moyen de le savoir maintenant.