Impossible de trouver l'élément de point de terminaison par défaut
J'ai ajouté un proxy à un webservice à une solution VS2008/. net 3.5. Lors de la construction du client. Net renvoie cette erreur:
Impossible de trouver l'élément de point de terminaison par défaut qui fait référence au contrat 'IMySOAPWebService' dans la section de configuration du client ServiceModel. Cela peut être dû au fait qu'aucun fichier de configuration n'a été trouvé pour votre application ou qu'aucun élément de point de terminaison correspondant à ce contrat n'a pu être trouvé dans l'élément client.
La recherche de cette erreur indique moi d'utiliser l'espace de noms complet dans le contrat. Voici l'une de mes applications.config avec l'espace de noms complet:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>
Je cours XP local (je le mentionne car un certain nombre de hits Google mentionnent win2k3) App.config est copié dans l'application.EXE.config, donc ce n'est pas non plus le problème.
Des indices?
30 réponses
" cette erreur peut survenir si vous appelez le service dans une bibliothèque de classes et appelez la bibliothèque de classes à partir d'un autre projet."
Dans ce cas, vous devrez inclure les paramètres de configuration WS dans l'application main projects.config si c'est un winapp ou web.config si c'est une application web. C'est la voie à suivre même avec PRISM et WPF/Silverlight.
Après avoir testé plusieurs options, j'ai finalement résolu cela en utilisant
Contrat="IMySOAPWebService"
C'est-à-dire sans l'espace de noms complet dans la configuration. Pour une raison quelconque, le nom complet n'a pas résolu correctement
J'ai résolu cela (je pense comme d'autres l'ont suggéré) en créant moi - même les instances d'adresse de liaison et de point de terminaison-parce que je ne voulais pas ajouter de nouveaux paramètres aux fichiers de configuration (ceci remplace un code de bibliothèque existant largement utilisé, et précédemment utilisé une référence de service Web plus ancienne, etc.), et donc je voulais pouvoir laisser tomber cela sans avoir à ajouter de nouveaux paramètres de configuration partout.
var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);
using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
//set timeout
productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);
//call web service method
productResponse = productService.GetProducts();
}
Modifier
Si vous utilisez https, vous devez utiliser BasicHttpsBinding
plutôt que BasicHttpBinding
.
, j'ai eu ce même problème. Il s'avère que pour une référence web, vous devez fournir L'URL comme premier paramètre au constructeur:
new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");
Pour une nouvelle référence de SERVICE Web de style, vous devez fournir un nom qui fait référence à une entrée de point de terminaison dans la configuration:
new WebService.WebServiceSoapClient("WebServiceEndpoint");
, Avec une entrée correspondante dans Web.config
ou App.config
:
<client>
<endpoint address="http://myservice.com/moo.aspx"
binding="basicHttpBinding"
bindingConfiguration="WebService"
contract="WebService.WebServiceSoap"
name="WebServiceEndpoint" />
</client>
</system.serviceModel>
Assez sacrément difficile d'enlever la vision du tunnel sur "cela a fonctionné dans un programme plus ancien"...
J'ai eu une situation comme celle-ci, où j'avais
- Service WCF hébergé quelque part
- Projet Principal
- projet consommateur de type 'class Library' qui a une référence de Service à un Service WCF
- Le projet principal appelle les méthodes du projet consommateur
Maintenant, le projet consommateur avait tous les paramètres de configuration associés dans la balise <system.serviceModel>
de mon application.config, c'était toujours la même erreur que ce qui précède.
Tout ce que j'ai fait est ajouté la même balise <system.serviceModel>
à mon principal projet app.fichier de configuration, et enfin nous étions prêts à partir.
Le vrai problème, dans mon cas, était qu'il lisait le mauvais fichier de configuration. Au lieu de consommateur de l'application.config, il faisait référence à la config de main proj. il m'a fallu deux heures pour comprendre cela.
" cette erreur peut survenir si vous appelez le service dans une bibliothèque de classes et appelez la bibliothèque de classes à partir d'un autre projet."
" dans ce cas, vous devrez inclure les paramètres de configuration WS dans l'application main projects.config si c'est un winapp ou web.config si c'est une application web. C'est la voie à suivre même avec PRISM et WPF/Silverlight."
Oui, mais si vous ne pouvez pas changer le projet principal (Orchard CMS par exemple), vous pouvez conserver la configuration du service WCF dans votre projet.
Vous devez créer un assistant de service avec la méthode de génération de client:
public static class ServiceClientHelper
{
public static T GetClient<T>(string moduleName) where T : IClientChannel
{
var channelType = typeof(T);
var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;
if (contractAttribute == null)
throw new Exception("contractAttribute not configured");
//path to your lib app.config (mark as "Copy Always" in properties)
var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName));
var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);
if (serviceModelSectionGroup == null)
throw new Exception("serviceModelSectionGroup not configured");
var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
var client = channelFactory.CreateChannel();
return client;
}
}
Et l'utiliser:
using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
... get data from service ...
}
Voir les détails dans cet article .
Celui-ci m'a rendu fou.
J'utilise Silverlight 3 Prism (CAB) avec WCF
Quand j'appelle un service WCF dans un module Prism, j'obtiens la même erreur:
Impossible de trouver l'élément de point de terminaison par défaut faisant référence au contrat 'IMyService' dans la section de configuration du client du modèle de service. Ce peut être parce qu'aucun fichier de configuration n'a été trouvé pour votre application ou parce qu'aucun élément de point final correspondant à ce contrat n'a pu être trouvé dans le client élément
Il s'avère que sa recherche dans la coquille .fichier XAP pour un ServiceReferences.ClientConfig, pas dans les ServiceReferences du module.Fichier ClientConfig. J'ai ajouté mon point de terminaison et la liaison aux ServiceReferences existantes.Fichier ClientConfig dans mon application Silverlight Shell (il appelle ses propres services WCF).
Ensuite, j'ai dû reconstruire L'application Shell pour générer le nouveau .fichier XAP pour le dossier ClientBin de mon projet Web.
Maintenant cette ligne de code enfin travaux:
MyServiceClient myService = new MyServiceClient();
Je recevais cette erreur dans un ASP.NET application où le service WCF a été ajouté à une bibliothèque de classes qui est ajoutée à la ASP.NET application en tant que référencé .fichier dll dans le dossier bin. Pour résoudre l'erreur, les paramètres de configuration de l'application.le fichier de configuration dans la bibliothèque de classes référençant le service WCF devait être copié sur le web.paramètres de configuration pour le ASP.NET site / app.
J'ai trouvé (ainsi que la copie à L'application de l'interface utilisateur du client.config comme j'utilisais une interface de bibliothèque de classes) j'ai dû préfixer le nom de la liaison avec le nom de la référence de Service (le mien est ServiceReference
dans le ci-dessous).
Par exemple:
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ServiceReference.ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
Au lieu de la valeur par défaut générée:
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
J'ai eu le MÊME PROBLÈME, MAIS changer l'espace de noms du contrat n'a pas fonctionné pour moi. J'ai donc essayé une référence web de style. Net 2 au lieu d'une référence de service.Net 3.5. Qui ont travaillé.
Pour utiliser une référence Web dans Visual Studio 2008, cliquez sur "Ajouter une référence de Service" , puis cliquez sur "Avancé" lorsque la boîte de dialogue s'affiche. En cela, vous trouverez une option qui vous permettra d'utiliser une référence Web au lieu d'une référence de Service.
Plusieurs réponses ici ont trouvé la bonne solution lorsque vous faites face à l'erreur obscure de référencer le service à partir d'un fichier de classe: copiez les informations de configuration du service dans votre application.config web.configuration de votre console ou de votre application windows. Aucune de ces réponses ne semble vous montrer quoi copier cependant. Nous allons essayer de remédier à cela.
Voici ce que j'ai copié du fichier de configuration de ma bibliothèque de classe, dans le fichier de configuration de mon application console, afin de contourner cette erreur folle pour un service que je écrire appelé "TranslationServiceOutbound".
Vous voulez essentiellement tout à l'intérieur du système .serviceModel section:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ITranslationServiceOutbound" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>
Le test unitaire d'une application non-bibliothèque qui consomme un service peut causer ce problème.
Les informations que d'autres ont saisies en résolvent la cause première. Si vous essayez d'écrire des cas de test automatisés et que l'unité que vous testez appellera réellement l'interface de service, vous devez ajouter la référence de service au projet de test. Ceci est une saveur de l'application en utilisant le type d'erreur de la bibliothèque. Je n'ai pas immédiatement réalisé cela parce que mon code qui consomme de l'interface n'est pas dans une bibliothèque. Cependant, lorsque le test s'exécute réellement, il sera exécuté à partir de l'assemblage de test, pas de l'assemblage testé.
L'ajout d'une référence de service au projet de test unitaire a résolu mon problème.
J'ai fait face à ce problème une fois. C'était parce que je développais encore l'interface qui utilise le service WCF. J'ai configuré l'application de test et le développement continu. Ensuite, en développement, j'ai changé certains espaces de noms des services. J'ai donc une double vérification "du système.serviceModel - > client - > Point de terminaison - > contrat " dans le web.config pour correspondre à la classe WCF. Puis le problème est résolu.
L'espace de noms dans votre configuration doit refléter le reste du chemin d'accès de l'espace de noms après l'espace de noms par défaut de votre client (tel que configuré dans les propriétés du projet). Sur la base de votre réponse publiée, je suppose que votre client est configuré pour être dans la "Fusion.DataExchange.Les flux de travail" espace de noms. Si vous avez déplacé le code client vers un autre espace de noms, Vous devez mettre à jour la configuration pour correspondre au chemin d'accès de l'espace de noms restant.
Juste pour quelqu'un d'autre avec le même problème; j'ai écrit un test unitaire pour ma méthode qui a essayé de se connecter à mon service. Il a échoué avec cette même exception à chaque fois-je ne sais pas pourquoi. Quand je l'ai couru à partir d'un winform, cela fonctionne bien.
J'ai le même problème.J'utilise le Service WCF dans la bibliothèque de classes et appelle la bibliothèque de classes à partir du projet d'Application windows.mais J'oublie le changement <system.serviceModel>
dans le fichier de configuration du projet d'application windows même le <system.serviceModel>
de l'application de la bibliothèque de classe.Fichier de configuration.
solution: changer la Configuration du projet externe même la configuration wcf de la bibliothèque de classes.
Si vous référencez le service web dans votre bibliothèque de classes, vous devez copier l'application.config à votre application windows ou application console
Solution: changer la Configuration du projet externe même la configuration wcf de la bibliothèque de classes.
Travaillé pour moi
Salut j'ai rencontré le même problème mais la meilleure solution est de laisser le. net configurer votre configuration côté client. Ce que je découvre est ceci quand j'ajoute une référence de service avec une chaîne de requête de http:/namespace/service.svc?WSDL = wsdl0 il ne crée pas de points de terminaison de configuration côté client. Mais quand je retire le?wsdl-wsdl0 et utilisez uniquement l'url http:/namespace/service.svc, il crée la configuration du point de terminaison dans le fichier de configuration du client. pour faire court elle l' " ?WSDL=WSDL0" .
Ne mettez pas la ligne de déclaration du client de service comme champ de classe, au lieu de cela, créez une instance à chaque méthode utilisée dans. Donc, le problème sera résolu. Si vous créez une instance de client de service en tant que champ de classe, une erreur de temps de conception se produit !
Dans le cas où vous utilisez l'application WPF en utilisant PRISM framework, la configuration devrait exister dans votre projet de démarrage (c'est-à-dire dans le projet où réside votre bootstrapper.)
Cette erreur peut survenir si vous appelez le service dans une bibliothèque de classes et appelez la bibliothèque de classes à partir d'un autre projet.
Il semble y avoir plusieurs façons de créer/résoudre ce problème. Pour moi, le produit CRM que j'utilise a été écrit en code natif et est capable d'appeler ma dll.net, mais je rencontre les informations de configuration qui doivent être au-dessus de l'application principale. Pour moi, L'application CRM n'est pas.net, donc j'ai fini par devoir le mettre dans ma machine.fichier de configuration (pas où je le veux). De plus, puisque mon entreprise utilise Websense, j'ai eu du mal à ajouter la référence de Service en raison d'une authentification Proxy 407 Problème requis, qui nécessite une modification de la machine.cong.
Solution Proxy:
Pour que la référence du Service WCF fonctionne, j'ai dû copier les informations de l'application.config de ma DLL à la configuration principale de l'application (mais pour moi c'était la machine.config). Et j'ai également dû copier les informations du point de terminaison dans ce même fichier. Une fois que je l'ai fait, il commence à travailler pour moi.
Ok. Mon cas était un peu différent mais finalement j'ai trouvé le correctif pour cela: J'ai une Console.EXE - > DLL - > invoquer WS1 - > DLL - > invoquer WS2
J'ai eu à la fois les configurations du modèle de service de WS1 et WS2 dans la Console.EXE.config comme recommandé. - pas de résoudre le problème.
Mais cela n'a toujours pas fonctionné, jusqu'à ce que j'ai ajouté la WebReference de WS2 à WS1 aussi et pas seulement à la DLL qui crée et invoque le proxy de WS2.
J'ai eu le même Problème
J'utilisais l'application de bureau et l'utilisation du service Web Global Weather
J'ai supprimé la référence de service et ajouté la référence web et le problème résolu Merci
La Solution pour moi était de supprimer le nom du point de terminaison de l'attribut Endpoint Name dans le Web client.config cela a permis au proxy d'utiliser
ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");
Il n'a fallu que toute la journée pour s'entraîner. De plus, le nom du contrat était erroné une fois que ce correctif était en place, bien qu'il ait été erroné lorsque l'erreur initiale apparaît. Double puis triple vérifier les chaînes de nom de contrat personnes !! attrib: Ian
Permettez-moi d'ajouter une autre chose à rechercher. (la réponse de Tom Haigh y fait déjà allusion, mais je veux être explicite)
Mon fichier web.config
avait la définition suivante:
<protocolMapping>
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
J'utilisais déjà basicHttpsBinding pour une référence, mais j'ai ensuite ajouté une nouvelle référence qui nécessitait basicHttpBinding (pas de s). Tout ce que je devais faire était d'ajouter cela à mon protocolMapping
comme suit:
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
Comme le souligne correctement L. R. , cela doit être défini aux bons endroits. Pour moi, cela signifiait un dans l'application de mon projet de test unitaire.config ainsi que l'un dans le Web du projet de service principal.config.
J'ai eu cette erreur lorsque je référencais le contrat dans l'élément de fichier de configuration sans l'opérateur global scope.
C'est-à-dire
<endpoint contract="global::MyNamepsace.IMyContract" .../>
Fonctionne, mais
<endpoint contract="MyNamepsace.IMyContract" .../>
Donne l'erreur "Impossible de trouver l'élément de point de terminaison par défaut qui fait référence au contrat".
L'ensemble contenant MyNamepsace.IMyContract est dans un assemblage différent de l'application principale, ce qui peut expliquer la nécessité d'utiliser la résolution de portée globale.
J'ai eu la même erreur et j'essaie beaucoup de choses mais n'a pas fonctionné, que j'ai remarqué que mon "contrat" n'était pas le même pour des projets entiers, j'ai changé le contrat comme le serait pour tous les projets à l'intérieur de la solution et que cela a fonctionné. C'est le projet a
<client>
<endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>
Projet B:
<client>
<endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>
Enfin, j'ai changé pour les deux comme:
<client>
<endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>
Lorsque vous ajoutez une référence de service
Méfiez-vous de l'espace de noms que vous tapez:
Vous devez l'ajouter au nom de votre interface:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding"
contract="MyNamespace.IMySOAPWebService" />
</client>