Impossible de trouver l'élément de point de terminaison par défaut

J'ai ajouté un proxy à un service Web à une solution VS2008 / .NET 3.5. Lors de la construction du client .NET génère 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 noeud final correspondant à ce contrat n'a pu être trouvé dans l'élément client.

La recherche de cette erreur me dit d'utiliser l'espace de noms complet 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 le mentionne car un certain nombre de hits Google mentionnent win2k3). L'app.config est copié dans app.exe.config, donc ce n'est pas non plus le problème.

Des indices?

"Cette erreur peut se produire 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.

J'ai résolu ce problème (je pense que d'autres l'ont suggéré) en créant moi-même les instances d'adresse de liaison et de point de terminaison - car je ne voulais pas ajouter de nouveaux paramètres aux fichiers de configuration (c'est un remplacement pour un code de bibliothèque existant qui est largement utilisé, et précédemment utilisé une ancienne référence de service Web, etc.), et donc je voulais pouvoir le déposer 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 BasicHttpsBindingplutôt que BasicHttpBinding.

Après avoir testé plusieurs options, j'ai finalement résolu cela en utilisant

contract = "IMySOAPWebService"

c'est-à-dire sans l'espace de noms complet dans la configuration. Pour une raison quelconque, le nom complet ne s'est pas résolu correctement

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 RÉFÉRENCE DE SERVICE Web de nouveau 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.configou 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 de supprimer la vision du tunnel sur "cela a fonctionné dans un programme plus ancien" ...

J'ai eu une situation comme ça, où j'avais

• Service WCF hébergé quelque part
• Projet principal
• Projet consommateur de type «bibliothèque de classes» qui a une référence de service à un service WCF
• Le projet principal appelle les méthodes du projet consommateur

Maintenant, le projet Consumer avait tous les paramètres de configuration associés dans <system.serviceModel> Tag de mon app.config, il affichait toujours la même erreur que ci-dessus.

Tout ce que j'ai fait est d'ajouter 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ù dans mon cas, c'était la lecture du mauvais fichier de configuration. Au lieu de l'app.config du consommateur, il faisait référence à la configuration principale du projet. il m'a fallu deux heures pour comprendre cela.

"Cette erreur peut se produire 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 (CMS Orchard 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 .

Plusieurs réponses ici trouvent la bonne solution lorsque vous faites face à l'erreur obscurcissante de référencer le service à partir d'un fichier de classe: copiez les informations de configuration du service dans votre app.config web.config de votre console ou application Windows. Aucune de ces réponses ne semble cependant vous montrer quoi copier. Essayons de corriger cela.

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 erreur folle pour un service que j'écris appelé "TranslationServiceOutbound".

Vous voulez essentiellement tout ce qui se trouve 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>

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 noeud final par défaut qui fait 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 de point final correspondant à ce contrat n'a pu être trouvé dans l'élément client.

Il s'avère que sa recherche dans le fichier .xap du shell pour 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 (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 fonctionne enfin:

MyServiceClient myService = new MyServiceClient();

J'obtenais cette erreur dans une application ASP.NET où le service WCF avait été ajouté à une bibliothèque de classes qui est ajoutée à l'application ASP.NET en tant que fichier .dll référencé dans le dossier bin. Pour résoudre l'erreur, les paramètres de configuration du fichier app.config de la bibliothèque de classes référençant le 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 le fichier App.config de l'interface utilisateur du client que j'utilisais une interface de bibliothèque de classes) que je devais préfixer le nom de la liaison avec le nom de la référence de service (le mien est ServiceReference 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 cliquez sur «Avancé» lorsque la boîte de dialogue apparaît. 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.

L'unité testant une application non bibliothèque qui utilise un service peut provoquer ce problème.

Les informations que d'autres personnes ont saisies répondent à la cause profonde de cela. Si vous essayez d'écrire des cas de test automatisés et que l'unité que vous testez invoquera réellement l'interface de service, vous devez ajouter la référence de service au projet de test. Il s'agit d'une version de l'application utilisant le type d'erreur de bibliothèque. Je ne l'ai pas réalisé tout de suite, car mon code qui consomme l'interface n'est pas dans une bibliothèque . Cependant, lorsque le test s'exécute, il s'exécute à partir de l'assembly de test, et non de l'assembly sous test.

L'ajout d'une référence de service au projet de test unitaire a résolu mon problème.

J'ai une situation qui dans le test unitaire. J'ai copié le fichier app.config dans le projet de test unitaire. Le projet de test unitaire contient donc également des informations sur les points finaux.

J'ai fait face à ce problème une fois. C'est parce que je développais encore l'interface qui utilise le service WCF. J'ai configuré l'application de test et poursuivi le développement. Puis en cours de développement, j'ai changé certains des espaces de noms des services. J'ai donc vérifié "system.serviceModel -> client -> endpoint -> contract" dans web.config pour correspondre à la classe WCF. Ensuite, le problème est résolu.

L'espace de noms dans votre configuration doit refléter le reste du chemin 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 l'espace de noms "Fusion.DataExchange.Workflows". Si vous avez déplacé le code client vers un autre espace de noms, vous devrez mettre à jour la configuration pour correspondre au chemin d'espace de noms restant.

J'ai un même Problem.I'm utilisé le service WCF dans la bibliothèque de classe et appeler la bibliothèque de classes de fenêtres d' application project.but Je suis Oublier le changement <system.serviceModel>dans la configuration Fichier d'application Windows projet même le <system.serviceModel>du fichier app.config de bibliothèque de classes.
solution: changez la configuration du projet externe de la même manière que la configuration wcf de la bibliothèque de classes.

Salut, j'ai rencontré le même problème, mais la meilleure solution est de laisser le .NET pour configurer votre configuration côté client. Ce que je découvre, c'est lorsque j'ajoute une référence de service avec une chaîne de requête http: /namespace/service.svc? Wsdl = wsdl0, cela ne crée PAS de points de terminaison de configuration côté client. Mais lorsque je supprime le? 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 court terme, le "? 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. 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 conception se produit!

Si vous utilisez une application WPF utilisant le framework PRISM, la configuration doit exister dans votre projet de démarrage (c'est-à-dire dans le projet où réside votre programme d'amorçage).

Cette erreur peut se produire 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 devant être au niveau / au-dessus de l'application principale. Pour moi, l'application CRM n'est pas .NET, j'ai donc dû la mettre dans mon fichier machine.config (pas là où je le voulais). De plus, étant donné que mon entreprise utilise Websense, j'ai même eu du mal à ajouter la référence de service en raison d'un problème d'authentification proxy 407 requis, qui nécessitait une modification du fichier machine.cong.

Solution proxy:

Pour que la référence de service WCF fonctionne, j'ai dû copier les informations du fichier app.config de ma DLL vers la configuration de l'application principale (mais pour moi, c'était 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, cela a commencé à travailler pour moi.

D'accord. Mon cas était un peu différent mais finalement j'ai trouvé le correctif: j'ai une Console.EXE -> DLL -> Invocation de WS1 -> DLL -> Invocation de WS2

J'ai eu à la fois les configurations du modèle de service WS1 et WS2 dans le fichier Console.EXE.config comme recommandé. - n'a pas résolu le problème.

Mais cela n'a toujours pas fonctionné, jusqu'à ce que j'ajoute également la référence Web de WS2 à WS1 et pas seulement à la DLL qui crée et appelle réellement le proxy de WS2.

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: changez la configuration du projet externe de la même manière que la configuration wcf de la bibliothèque de classes.

Travaillé pour moi

J'ai eu le même problème
j'utilisais l'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 a été résolu Merci

La solution pour moi a été de supprimer le nom du point de terminaison de l'attribut Endpoint Name dans le client web.config, ce qui a permis au proxy d'utiliser

ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");

n'a pris que toute la journée pour s'entraîner. De plus, le nom du contrat était incorrect une fois que ce correctif était en place, bien qu'il ait été incorrect lorsque l'erreur initiale apparaît. Double puis triple vérification pour les personnes de chaînes de nom de contrat !! attrib: Ian

Permettez-moi d'ajouter une chose à rechercher. ( La réponse de Tom Haigh y fait déjà allusion, mais je veux être explicite)

Mon web.configfichier 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 j'avais à faire était d'ajouter cela à mon protocolMappingcomme suit:

<protocolMapping>
    <add binding="basicHttpBinding" scheme="http" />
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Comme LR le souligne correctement, cela doit être défini aux bons endroits. Pour moi, cela signifiait un dans app.config de mon projet de test unitaire ainsi qu'un dans le web.config du projet de service principal.

J'ai eu cette erreur lorsque je référençais le 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 l'application principale, cela peut donc expliquer la nécessité d'utiliser la résolution de portée globale.

Lorsque vous ajoutez une référence de service

méfiez-vous de l'espace de noms que vous saisissez:

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>

J'ai eu la même erreur et j'ai essayé beaucoup de choses mais n'ai pas fonctionné, j'ai remarqué que mon "contrat" ​​n'était pas le même pour tous les projets, j'ai changé le contrat comme il le serait pour tous les projets à l'intérieur de la solution et 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>

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 point de terminaison avaient le même nom de référence de service.