J'ai créé un projet de bibliothèque de services WCF dans ma solution, auquel sont référencés les services. 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 directement - ils ne sont modifiés que pour obtenir les fonctions de service async.
Tout fonctionnait bien - jusqu'à ce que je veuille mettre à jour mes références de service. Il a échoué, alors j’ai fini par revenir en arrière et réessayer, mais il a échoué malgré tout! Donc - la mise à jour des références de service échoue sans y apporter de modification. Pourquoi?!
L'erreur que je reçois 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 cela très déroutant. Je n'ai pas de classe Patient dans le tableau de bord côté client, à l'exception de celle que j'ai obtenue via la référence de service. Alors qu'est-ce que cela signifie? Et pourquoi cela se voit-il soudainement? Rappelez-vous: je n'ai même rien changé!
Maintenant, la solution à ceci a été trouvée ici , mais sans une explication de ce que cela signifie. Alors; dans la case "Configurer la référence de service" pour le service, décochez la case "Réutiliser les types dans les assemblys référencés". Reconstruire maintenant tout fonctionne bien sans problèmes. Mais qu'est-ce que j'ai vraiment changé? Cela aura-t-il un impact sur ma candidature? Et quand faut-il décocher cela? Je souhaite réutiliser les types sur lesquels j'ai configuré DataContract, mais pas plus. Aurai-je toujours accès à ceux qui ne sont pas cochés?
Lorsque vous ajoutez une référence de service, les types utilisés par le service peuvent être gérés de deux manières:
Il y a beaucoup de choses qui peuvent aller mal. Nous avons constaté que si l'outil se bloque, 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 avons le contrôle du client et du service, nous utilisons la méthode décrite dans ce screencast .
J'ai trouvé ma réponse ici: http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html
Longue histoire: j'ai décoché les types de réutilisation dans les assemblys de référence à partir du menu Avancé .
Je ne sais pas si cela compte, mais je n'utilise pas MVC, mais Web Forms.
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 ça 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 en tant que DataMember et l'énumération est également marquée en tant que 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 ça a finalement fonctionné!
Accédez aux propriétés avancées lors de l'ajout d'une référence et supprimez "System.Window.Browser" de la liste de contrôle, le problème est résolu.
cela peut paraître bizarre, mais je l’ai résolu en supprimant les références, puis en fermant Visual Studio, en le rouvrant à nouveau et en ajoutant enfin les références.
Je pense que l'outil personnalisé devait être redémarré ou quelque chose du genre.
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 sur ma machine virtuelle, j'ai essayé de fermer Visual Studio, puis de le rouvrir avec "Exécuter en tant qu'administrateur" et cela a fonctionné comme par magie.
Bonne chance.
J'ai reçu cet avertissement après avoir mis à niveau ma solution de Visual Studio (VS) 2010 à 2013 et modifié le .NET Framework de chaque projet de 4 à 4.5.1. J'ai fermé le VS et ai rouvert et les avertissements sont partis.
Un des inconvénients de la désactivation des 'types de réutilisation 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 a créé ces objets à nouveau 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 ceux qui ne contiennent que des références ambiguës, ce qui résout rapidement le problème de cette façon.
J'espère que ça aide quelqu'un d'autre.
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
Le fichier est complètement vide à chaque fois et cela faisait littéralement des années que je l’avais créé. Il était donc hors de question de tenter 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 concerne réellement la version Silverlight, mais cela m'a fait penser à la création d'un tout nouveau projet, puis tout a fonctionné.
Avertissement 2 Outil personnalisé Avertissement: Impossible d'importer wsdl: portType Détails: Une exception a été générée lors de l'exécution d'une extension d'importation WSDL: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Erreur: Impossible de charger le fichier ou l'assembly 'System.Xml, Version = 2.0.5.0, Culture = neutre, PublicKeyToken = 7cec85d7bea7798e 'ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. XPath to Error Source: // wsdl: définitions [@targetNamespace = '']/wsdl: port Type [@ name = 'IShoppingCart']
Je regardais mon projet et j'avais le même problème. Il s’est avéré qu’il s’agissait de versions différentes du même DLL sur le site Web de la WCF par rapport à celui-ci. Le site Web comportait une version plus récente du DLL et le service était référençant une ancienne version de la DLL, ils fonctionnaient tous bien une fois qu'ils étaient synchronisés.
Mes interfaces du service WCF sont dans un assembly, l'implémentation en est une autre et la référence de service se trouve dans 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é DataContract à un enum. Après avoir appliqué EnumMember aux champs de l'énum, le problème a été résolu.
Pour tous ceux qui se trouvent 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 paquet de nuget des deux côtés et j'ai essayé de mettre à jour la référence de service et j'ai obtenu cette erreur.
La suppression n'a pas aidé. Décocher "réutiliser les assemblages" n’est pas souhaitable car je dois les réutiliser - c’est l’essentiel.
À la fin, il y avait deux problèmes distincts:
1) Le premier problème, je crois, était un problème de mise en cache de Visual Studio. J'ai examiné méticuleusement toutes les références et n'ai trouvé aucun problème, mais le système signalait toujours qu'il était impossible de trouver la version précédente du fichier. J'ai désinstallé tous les packages de pépites, 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 a été causé par un problème de dépendance. J'ai mis à jour le paquet de pépites des deux côtés et tout semblait correct, mais une dépendance non marquée était désynchronisée. Exemple:
Le paquet Foo v1 fait référence à Bar v1. Il est possible de mettre à jour Foo and Bar vers 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, consultez la référence à Bar v1 et échoue car il ne trouve pas l'ancienne version. Ceci n'est signalé correctement que si vous mettez à jour les numéros de version de votre dll pour chaque paquet. Visual Studio et MSBuild n'auront aucun problème à créer l'application, mais la référence de service aura beaucoup de mal à tout résoudre.
J'espère que ça aidera quelqu'un.
J'ai vécu la même erreur. J'ai passé presque une journée à lutter pour essayer de comprendre ce qui n'allait pas. L'indice pour moi était les avertissements que VS lançait. Il essayait de faire une sorte de mappage vers Yahoo.Yui.Compressor.dll, une bibliothèque que j'avais ajoutée et supprimée (parce que 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 certaine manière, elle essayait de la référencer.
Enfin, je restaure cette dll à partir de la corbeille, puis je peux mettre à jour ma référence de service avec succès.