Impossible de trouver l'élément par défaut
J'ai ajouté un proxy à un service Web à une solution VS2008/.NET 3.5. Lors de la construction du client .NET lève cette erreur:
Impossible de trouver l'élément de noeud final par défaut faisant 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 d'extrémité correspondant à ce contrat n'a été trouvé dans l'élément client.
La recherche de cette erreur m'indique d'utiliser l'intégralité de l'espace de noms dans le contrat. Voici mon app.config avec un 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>
J'utilise XP local (je mentionne cela car un certain nombre de hits Google mentionnent win2k3). App.config est copié dans app.exe.config. Ce n'est donc pas le problème.
Des indices?
Après avoir testé plusieurs options, j'ai finalement résolu ce problème en utilisant
contract = "IMySOAPWebService"
c'est-à-dire sans l'espace de noms complet dans la configuration. Pour une raison quelconque, le nom complet n'a pas été résolu correctement
"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 le projet principal app.config s'il s'agit d'une application winapp ou web.config s'il s'agit d'une application Web. C'est la voie à suivre même avec PRISM et WPF/Silverlight.
J'ai résolu ce problème (comme l'ont suggéré d'autres personnes) en créant moi-même les instances de liaison et d'adresse de point final, car je ne souhaitais pas ajouter de nouveaux paramètres aux fichiers de configuration (ceci remplace un code de bibliothèque existant qui est largement utilisé, et utilisait auparavant une référence de service Web plus ancienne, etc.) et je voulais donc pouvoir y insérer ce contenu 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();
}
Éditer
Si vous utilisez https, vous devez utiliser BasicHttpsBinding plutôt que BasicHttpBinding.
J'ai eu le même problème. Il s'avère que pour une référence Web, vous devez fournir l'URL en tant que premier paramètre au constructeur:
new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");
Pour un nouveau style SERVICE REFERENCE Web, vous devez fournir un nom faisant référence à une entrée de noeud final 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>
C'est sacrément difficile de supprimer la vision 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
- Principales méthodes d'appels à projet du projet consommateur
Maintenant, le projet consommateur avait tous les paramètres de configuration associés dans <system.serviceModel> Balise de mon app.config, il lançait toujours la même erreur que ci-dessus.
Tout ce que j'ai fait est ajouté la même balise <system.serviceModel> au fichier app.config de mon projet principal, et finalement nous étions prêts à partir.
Le vrai problème, dans la mesure où ce fut mon cas, était de lire le mauvais fichier de configuration. Au lieu de l'app.config du consommateur, il faisait référence à la configuration principale de 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 les projets principaux app.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 modifier 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 une 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
Lorsque 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. Cela peut être dû au fait qu'aucun fichier de configuration n'a été trouvé pour votre application ou qu'aucun élément d'extrémité correspondant à ce contrat n'a été trouvé dans l'élément client.
En fait, il recherche dans le fichier .xap du shell un fichier ServiceReferences.ClientConfig, pas dans le fichier ServiceReferences.ClientConfig du module. J'ai ajouté mon point de terminaison et ma liaison au fichier ServiceReferences.ClientConfig existant dans mon application Silverlight Shell (elle 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 fonctionne enfin:
MyServiceClient myService = new MyServiceClient();
Plusieurs réponses ici trouvent la bonne solution lorsque vous faites face à l'erreur obscure et 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.config de votre console ou de votre application Windows. Aucune de ces réponses ne semble vous montrer quoi copier. Essayons de corriger ça.
Voici ce que j'ai copié du fichier de configuration de ma bibliothèque de classes dans le fichier de configuration de mon application console, afin de contourner cette folle erreur pour un service que j'écris appelé "TranslationServiceOutbound".
En gros, vous voulez tout dans la section system.serviceModel:
<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>
Je recevais cette erreur dans une application ASP.NET où le service WCF avait été ajouté à une bibliothèque de classes en cours d'ajout à l'application ASP.NET en tant que fichier référencé .dll dans le dossier bin. Pour résoudre l'erreur, les paramètres de configuration du fichier app.config de la bibliothèque de classes faisant référence au service WCF devaient être copiés dans les paramètres web.config du site/de l'application ASP.NET.
J'ai trouvé (ainsi que la copie dans App.config de l'interface utilisateur du client car j'utilisais une interface de bibliothèque de classes), je devais préfixer le nom de la liaison avec le nom de la référence de service (le mien est ServiceReference dans la liste 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 la modification de 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. Ça a marché.
Pour utiliser une référence Web dans Visual Studio 2008, cliquez sur "Ajouter une référence de service", puis sur "Avancé" lorsque la boîte de dialogue apparaît. Vous y trouverez une option qui vous permettra d'utiliser une référence Web au lieu d'une référence de service.
J'ai une situation qui dans le test unitaire. J'ai copié le fichier app.config dans le projet de test unitaire. Ainsi, le projet de test unitaire contient également des informations sur les points finaux.
L'unité qui teste une application hors bibliothèque qui utilise un service peut être à l'origine de ce problème.
Les informations que d'autres ont saisies en traitent. Si vous essayez d'écrire des scénarios de test automatisés et que l'unité que vous testez invoquera l'interface de service, vous devez ajouter la référence de service au projet de test. Ceci est une variante de l'application utilisant le type d'erreur de bibliothèque. Cependant, je ne m'en suis pas rendu compte immédiatement car mon code consommant l'interface n'est pas dans une bibliothèque. Toutefois, lorsque le test sera exécuté, il sera exécuté à partir de l’ensemble de test, et non de l’ensemble à tester.
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 toujours l'interface qui utilise le service WCF. J'ai configuré l'application de test et poursuivi le développement. Ensuite, en développement, j'ai modifié certains des espaces de noms des services. J'ai donc vérifié deux fois "system.serviceModel -> client -> endpoint -> contract" dans web.config pour faire correspondre la classe WCF. Alors le problème est résolu.
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 exécuté à partir d'un winform, cela fonctionne bien.
L'espace de noms dans votre configuration doit refléter le reste du chemin d'accès à 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). D'après votre réponse, je suppose que votre client est configuré pour figurer dans l'espace de noms "Fusion.DataExchange.Workflows". Si vous avez déplacé le code client vers un autre espace de nom, vous devez mettre à jour la configuration pour qu'elle corresponde au chemin d'accès à l'espace de nom restant.
Bonjour, j’ai rencontré le même problème, mais la meilleure solution consiste à laisser le .NET configurer votre configuration côté client. Ce que je découvre, c’est que c’est lorsque j’ajoute une référence de service avec une chaîne de requête http: /namespace/service.svc? Wsdl = wsdl0 il ne crée PAS de points de terminaison de configuration côté client. Mais lorsque je supprime? Wsdl-wsdl0 et n'utilise que 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 supprimer le "? WSDL = WSDL0".
Ne mettez pas la ligne de déclaration du client de service en tant que champ de classe. Au lieu de cela, créez une instance pour chaque méthode utilisée. Le problème sera donc 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!
Si vous utilisez une application WPF avec PRISM Framework, la configuration doit exister dans votre projet de démarrage (c'est-à-dire dans le projet où réside votre programme d'amorçage.)
Si vous référencez le service Web dans votre bibliothèque de classes, vous devez copier app.config dans votre application Windows ou votre application console.
solution: changer la configuration du projet externe identique à la configuration wcf de la bibliothèque de classes.
A travaillé pour moi
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 peut appeler ma dll .NET, mais je rencontre des informations de configuration qui doivent être identiques à celles de l'application principale. Pour moi, l'application CRM n'est pas .NET et j'ai donc dû la placer dans mon fichier machine.config (et non pas où je le voulais). De plus, étant donné que ma société utilise Websense, j'ai même eu du mal à ajouter la référence de service en raison d'un problème d'authentification requise du proxy 407, qui nécessitait une modification du fichier machine.cong.
Solution proxy:
Pour que la référence de service WCF fonctionne, je devais copier les informations du fichier app.config de mon DLL dans la configuration de l'application principale (mais pour moi, c'était machine.config). Et j'ai également dû copier les informations de point final dans ce même fichier. Une fois que j'ai fait ça commence à travailler pour moi.
J'ai eu le même problème
J'utilisais une application de bureau et le 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
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.
J'ai eu cette erreur lorsque je faisais référence au contrat dans l'élément de fichier de configuration sans l'opérateur de portée globale.
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'assembly contenant MyNamepsace.IMyContract se trouve dans un assembly différent de celui de l'application principale. Cela peut donc expliquer la nécessité d'utiliser la résolution de portée globale.
Permettez-moi d'ajouter une dernière chose à rechercher. ( La réponse de Tom Haigh y fait déjà allusion, mais je veux être explicite)
Mon fichier web.config avait les paramètres suivants définis:
<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 (no s). Tout ce que je devais faire était d’ajouter cela à ma protocolMapping comme suit:
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
Comme L.R. le souligne correctement, cela doit être défini aux bons endroits. Pour moi, cela signifiait un dans le fichier app.config de mon projet de test unitaire ainsi qu'un autre dans le fichier web.config du projet de service principal.
J'ai eu la même erreur et j'ai essayé quelque chose mais je n'ai pas fonctionné, mais j'ai remarqué que mon "contrat" n'était pas identique pour des projets entiers. 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>
La solution pour moi consistait à supprimer le nom du noeud final de l'attribut Nom du noeud final dans le client web.config, ce qui permettait au proxy d'utiliser
ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");
seulement pris toute la journée pour travailler. De plus, le nom du contrat était incorrect une fois que ce correctif était en place, bien qu'il se soit trompé lorsque l'erreur initiale s'est produite. Double puis triple contrôle pour le nom du contrat des chaînes de personnes !! attrib: Ian
D'accord. Mon cas était un peu différent, mais j'ai finalement trouvé le correctif: j'ai un Console.EXE -> DLL -> Invoquant WS1 -> DLL -> Invoquant WS2
J'ai eu les deux configurations du modèle de service de WS1 et WS2 dans le fichier Console.EXE.config comme recommandé. - n'a pas résolu le problème.
Mais cela ne fonctionnait toujours pas, jusqu'à ce que j'ajoute le WebReference de WS2 à WS1 également et pas seulement au DLL qui crée et appelle le proxy de WS2.
Lorsque vous ajoutez une référence de service
méfiez-vous de l'espace de noms que vous tapez:
Vous devriez l'ajouter au nom de votre interface:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding"
contract="MyNamespace.IMySOAPWebService" />
</client>
Dans mon cas, je faisais référence à ce service depuis un projet-cadre. Une fois que j'ai copié la section à la configuration du projet de démarrage principal, le problème a été résolu.
J'ai eu le même problème et il n'a été résolu que lorsque l'application hôte et la dll qui utilisaient ce noeud final avaient le même nom de référence de service.