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

Question

J'ai ajouté un proxy à un webservice dans une solution VS2008/.NET 3.5. Lors de la construction du client, .NET génère cette erreur :

Impossible de trouver l'élément endpoint 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 me dit d'utiliser l'espace de noms complet dans le contrat. Voici mon app.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>

J'utilise XP local (je le mentionne car un certain nombre de résultats de Google mentionnent win2k3). L'app.config est copié dans app.exe.config, donc ce n'est pas non plus le problème.

Des indices ?

Answer 1

"Cette erreur peut survenir si vous appelez le service dans une bibliothèque de classes et que vous appelez la bibliothèque de classes depuis un autre projet."

Dans ce cas, vous devrez inclure les paramètres de configuration de WS dans le fichier app.config du projet principal s'il s'agit d'une application Windows ou web.config s'il s'agit d'une application Web. C'est la méthode à suivre, même avec PRISM et WPF/Silverlight.

Answer 2

J'ai résolu ce problème (comme d'autres l'ont peut-être suggéré) en créant moi-même les instances de liaison et d'adresse de point de terminaison - parce que je ne voulais pas ajouter de nouveaux paramètres aux fichiers de configuration (il s'agit du remplacement d'un code de bibliothèque existant qui est largement utilisé, et qui utilisait auparavant une ancienne référence de service Web, etc.

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 alors vous devez utiliser BasicHttpsBinding plutôt que BasicHttpBinding .

Answer 3

Après avoir testé plusieurs options, j'ai finalement résolu le problème en utilisant la méthode suivante

contract="IMySOAPWebService"

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

Answer 4

J'ai eu le même problème. Il s'avère que pour une REFERENCE web, vous devez fournir l'URL comme premier paramètre du constructeur :

new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");

Pour un nouveau style de SERVICE REFERENCE web, 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>

Il est très difficile d'enlever la vision étroite du "ça marchait dans un ancien programme"...

Answer 5

J'ai eu une situation comme celle-là, 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 des méthodes du projet consommateur

Maintenant, le projet Consumer a tous les paramètres de configuration connexes dans le fichier <system.serviceModel> Tag de mon app.config, la même erreur que celle mentionnée ci-dessus s'est produite.

Tout ce que j'ai fait, c'est ajouter le même tag <system.serviceModel> au fichier app.config de mon projet principal, 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 l'app.config du consommateur, il se référait à la configuration du projet principal. Il m'a fallu deux heures pour le découvrir.