J'ai créé un projet de bibliothèque de services WCF dans ma solution et j'ai des références de service à ce sujet. J'utilise les services d'une bibliothèque de classes, j'ai donc des références de mon projet d'application WPF en plus de la bibliothèque de classes. Les services sont configurés simplement - uniquement modifiés pour obtenir les fonctions de service asynchrone.
Tout fonctionnait bien - jusqu'à ce que je veuille mettre à jour mes références de service. Cela a échoué, alors j'ai fini par reculer et réessayer, mais cela a échoué même dans ce cas! Donc, la mise à jour des références de service échoue sans y apporter de modifications. Pourquoi?!
L'erreur que j'obtiens est celle-ci:
Custom tool error: Failed to generate code for the service reference
'MyServiceReference'. Please check other error and warning messages for details.
L'avertissement donne plus d'informations:
Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension:
System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: List of referenced types contains more than one type with data contract name 'Patient' in
namespace 'http://schemas.datacontract.org/2004/07/MyApp.Model'. Need to exclude all but one of the
following types. Only matching types can be valid references:
"MyApp.Dashboard.MyServiceReference.Patient, Medski.Dashboard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching)
"MyApp.Model.Patient, MyApp.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching)
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType[@name='ISomeService']
Il y a aussi deux avertissements similaires disant:
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://tempuri.org/']/wsdl:portType[@name='ISomeService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_ISomeService']
Et la même chose pour:
Custom tool warning: Cannot import wsdl:port ..
Je trouve tout cela déroutant. Je n'ai pas de classe Patient sur le tableau de bord côté client à l'exception de celle que j'ai obtenue via la référence du service. Alors qu'est-ce que ça veut dire? Et pourquoi cela se voit-il soudainement? Souvenez-vous: je n'ai même rien changé!
Maintenant, la solution à cela a été trouvée ici , mais sans explication sur ce que cela signifie. Donc; dans la "Configurer la référence de service" pour le service, je décoche la case "Réutiliser les types dans les assemblys référencés". Reconstruire maintenant tout fonctionne correctement sans problèmes. Mais qu'est-ce que j'ai vraiment changé? Cela aura-t-il un impact sur ma candidature? Et quand doit-on décocher cela? Je souhaite réutiliser les types sur lesquels j'ai configuré DataContract, mais pas plus. Est-ce que j'aurai toujours accès à ceux sans cette vérification?
la source
Réponses:
Lorsque vous ajoutez une référence de service, il existe deux manières de gérer les types utilisés par le service:
Il y a beaucoup de choses qui peuvent mal tourner. Nous avons constaté que si l'outil plante, il est parfois plus rapide de supprimer la référence de service et de recommencer.
Nous avons cessé d'utiliser la référence de service. Pour les projets où nous contrôlons le client et le service, nous utilisons la méthode décrite dans ce screencast .
la source
J'ai trouvé ma réponse ici: http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html
En bref: j'ai décoché les types de réutilisation dans les assemblages de référence dans le menu Avancé .
Je ne sais pas si cela compte mais je n'utilise pas MVC, mais Web Forms.
la source
J'ai aussi eu ce problème aujourd'hui. Il m'a fallu une journée entière pour trouver mon erreur. J'espère que cela aide.
Ma classe qui n'a pas pu être importée a une propriété de type cutom enum. Cette propriété est marquée comme DataMember et l'énumération est également marquée comme DataContract. Tout va bien jusqu'à présent. J'ai juste oublié de marquer chaque membre enum comme EnumMember.
Alors j'ai changé
[DataContract] public enum SortMethodType { Default = 0, Popularity = 1, ReleaseDate = 2, PublishedDate = 3, TranslatedTitle = 4, OriginalTitle = 5, UserRating = 6, Duration = 7 }
Pour ça:
[DataContract] public enum SortMethodType { [EnumMember] Default = 0, [EnumMember] Popularity = 1, [EnumMember] ReleaseDate = 2, [EnumMember] PublishedDate = 3, [EnumMember] TranslatedTitle = 4, [EnumMember] OriginalTitle = 5, [EnumMember] UserRating = 6, [EnumMember] Duration = 7 }
Et cela a finalement fonctionné!
la source
Allez dans les propriétés avancées tout en ajoutant une référence et supprimez "System.Window.Browser" de la liste de contrôle, cela résout le problème.
la source
cela peut sembler étrange, mais je l'ai corrigé en supprimant les références, puis en fermant Visual Studio, en le rouvrant et en ajoutant enfin les références à nouveau.
Je pense que l'outil personnalisé devait être redémarré ou quelque chose du genre.
la source
Je rencontre constamment cette erreur alors qu'elle fonctionne sur une autre machine de développement. Même si je suis un administrateur complet partout dans ma machine virtuelle, j'ai essayé de fermer Visual Studio et de rouvrir avec `` Exécuter en tant qu'administrateur '' et cela a fonctionné comme par magie.
Bonne chance.
la source
J'ai reçu l'avertissement après la mise à niveau de ma solution de Visual Studio (VS) 2010 à 2013 et la modification du .NET Framework de chaque projet de 4 à 4.5.1. J'ai fermé VS et rouvert et les avertissements ont disparu.
la source
Un inconvénient de la désactivation de la «réutilisation des types dans les assemblys référencés» est que cela peut entraîner des problèmes avec des références ambiguës. Cela est dû au fait que la référence de service crée à nouveau ces objets dans le fichier .cs de référence et que votre code implémentant le service peut les référencer à partir de l'espace de noms d'origine.
Lorsque ce scénario se produit, je trouve utile de vérifier les `` types de réutilisation dans les assemblys référencés spécifiés '', ce qui me permet de choisir uniquement ceux avec des références ambiguës, ce qui résout rapidement le problème de cette façon.
J'espère que cela aide quelqu'un d'autre.
la source
Mes interfaces du service WCF sont dans un assembly, l'implémentation est dans un autre et la référence de service est dans encore un autre assembly, distinct des clients de la référence de service. J'ai reçu le message d'erreur juste après avoir appliqué le DataContract à une énumération. Après avoir appliqué EnumMember aux champs de l'énumération, le problème a été résolu.
la source
En cas de doute sur le fait que votre service n'a pas de problèmes (tels que des problèmes d'énumérations ou de classes non sérialisables comme mentionné par d'autres), essayez de créer un nouveau projet avec une nouvelle référence.
J'utilise Silverlight 5 et j'avais essayé de supprimer et de recréer la référence plusieurs fois. Le
reference.cs
fichier venait juste d'être complètement vide à chaque fois et cela faisait littéralement des années que je ne l'avais pas créé, il était donc hors de question d'essayer de comprendre ce qui avait changé dans le service.J'ai remarqué que l'erreur contenait des références à 2.0.5.0. Maintenant, je ne sais même pas si cela est réellement pertinent pour la version Silverlight, mais cela m'a fait penser à simplement créer un tout nouveau projet et puis tout a fonctionné.
la source
Je regardais mon projet et j'avais ce même problème. Il s'est avéré qu'il s'agissait de versions différentes de la même DLL sur le site WCF et sur le site Web. Le site Web avait une version plus récente de la DLL et le service faisait référence à une ancienne version de la DLL. Une fois qu'ils étaient tous synchronisés, tout fonctionnait bien.
la source
J'ai vécu la même erreur. J'ai lutté pendant presque une journée pour essayer de découvrir ce qui n'allait pas. L'indice pour moi était les avertissements lancés par VS. Il essayait de faire une sorte de mappage vers Yahoo.Yui.Compressor.dll, une bibliothèque que j'avais ajoutée et supprimée (car j'avais décidé de ne pas l'utiliser) quelques jours auparavant. C'était choquant parce que la bibliothèque n'était pas là, mais d'une manière ou d'une autre, elle essayait de la référencer.
Enfin, je restaure cette dll à partir de la corbeille, puis je pourrais mettre à jour ma référence de service avec succès.
la source
Pour quiconque ici à l'avenir, j'ai eu la même erreur mais causée par des problèmes de version, de deux manières différentes.
J'ai deux services WCF et deux applications clientes qui parlent via les références de service. J'ai mis à jour un package nuget des deux côtés et j'ai essayé de mettre à jour la référence du service et j'ai obtenu cette erreur.
La suppression n'a pas aidé. Décocher "réutiliser les assemblys" n'est pas souhaitable car je dois les réutiliser - c'est tout le but.
En fin de compte, il y avait deux problèmes distincts:
1) Le premier problème, je crois, était un problème de mise en cache du studio visuel. J'ai méticuleusement passé en revue toutes les références et n'ai trouvé aucun problème, mais il a quand même signalé ne pas pouvoir trouver la version précédente du fichier. J'ai désinstallé tous les packages nuget, redémarré Visual Studio et les ai réinstallés. La mise à jour de la référence de service a fonctionné.
2) Le deuxième problème était dû à un problème de dépendance. J'ai mis à jour le package nuget des deux côtés et tout semblait correct, mais une dépendance non marquée était désynchronisée. Exemple:
Le package Foo v1 fait référence à Bar v1. Il est possible de mettre à jour Foo et Bar en v2 indépendamment sans mettre à jour la référence. Si vous installez à la fois Foo et Bar v2, l'outil de référence de service analysera Foo v2, voir la référence à Bar v1, et échouera car il ne trouve pas l'ancienne version. Cela n'est signalé correctement que si vous mettez à jour les numéros de version de votre dll pour chaque package. Visual Studio et MSBuild n'auront aucun problème à créer l'application, mais la référence de service aura du mal à tout résoudre.
J'espère que ça aidera quelqu'un.
la source