Impossibile trovare l'elemento endpoint predefinito

Ho aggiunto un proxy a un servizio Web a una soluzione VS2008 / .NET 3.5. Durante la costruzione del client .NET genera questo errore:

Impossibile trovare l'elemento endpoint predefinito che fa riferimento al contratto "IMySOAPWebService" nella sezione di configurazione del client ServiceModel. Ciò può essere dovuto al fatto che non è stato trovato alcun file di configurazione per l'applicazione o perché non è stato trovato alcun elemento endpoint corrispondente a questo contratto nell'elemento client.

La ricerca di questo errore mi dice di utilizzare l'intero spazio dei nomi nel contratto. Ecco il mio app.config con spazio dei nomi completo:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
            contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>

Sto eseguendo XP local (menziono questo perché un numero di hit di Google menzionano win2k3) app.config viene copiato in app.exe.config, quindi anche questo non è un problema.

Qualche indizio?

"Questo errore può verificarsi se si chiama il servizio in una libreria di classi e si chiama la libreria di classi da un altro progetto."

In questo caso dovrai includere le impostazioni di configurazione WS nel progetto principale app.config se è un winapp o web.config se è un'app web. Questa è la strada da percorrere anche con PRISM e WPF / Silverlight.

Ho risolto questo problema (penso come potrebbero aver suggerito altri) creando personalmente le istanze dell'indirizzo di associazione e dell'endpoint, poiché non volevo aggiungere nuove impostazioni ai file di configurazione (si tratta di un sostituto per alcuni codici di libreria esistenti ampiamente utilizzati, e precedentemente usato un vecchio riferimento al servizio Web ecc.), e quindi volevo poterlo inserire senza aggiungere nuove impostazioni di configurazione ovunque.

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();
} 

modificare

Se si utilizza https, è necessario utilizzare BasicHttpsBindinganzichéBasicHttpBinding .

Avendo testato diverse opzioni, ho finalmente risolto usando

contratto = "IMySOAPWebService"

cioè senza l'intero spazio dei nomi nella configurazione. Per qualche ragione il nome completo non è stato risolto correttamente

Ho avuto lo stesso problema. Si scopre che per un RIFERIMENTO web, è necessario fornire l'URL come primo parametro al costruttore:

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

Per un riferimento di SERVIZIO web di nuovo stile, è necessario fornire un nome che faccia riferimento a una voce dell'endpoint nella configurazione:

new WebService.WebServiceSoapClient("WebServiceEndpoint");

Con una voce corrispondente in Web.configo App.config:

<client>
      <endpoint address="http://myservice.com/moo.aspx"
        binding="basicHttpBinding" 
        bindingConfiguration="WebService"
        contract="WebService.WebServiceSoap"
        name="WebServiceEndpoint" />
    </client>
  </system.serviceModel>

Abbastanza difficile rimuovere la visione del tunnel su "ha funzionato in un programma precedente" ...

Ho avuto una situazione come questa, dove ho avuto

• Servizio WCF ospitato da qualche parte
• Progetto principale
• Progetto consumer di tipo "class library" che ha un riferimento di servizio a un servizio WCF
• Il progetto principale chiama i metodi dal progetto del consumatore

Ora il progetto Consumer aveva tutte le relative impostazioni di configurazione <system.serviceModel> Tag della mia app.config, stava ancora generando lo stesso errore di cui sopra.

Tutto quello che ho fatto è stato aggiungere lo stesso tag <system.serviceModel>al file app.config del mio progetto principale e alla fine siamo stati pronti.

Il vero problema, per quanto riguarda il mio caso, stava leggendo il file di configurazione errato. Invece di app.config del consumatore, si riferiva alla configurazione del proj principale. mi ci sono volute due ore per capirlo.

"Questo errore può verificarsi se si chiama il servizio in una libreria di classi e si chiama la libreria di classi da un altro progetto."

"In questo caso dovrai includere le impostazioni di configurazione WS nel progetto principale app.config se è un winapp o web.config se è un'app web. Questo è il modo di procedere anche con PRISM e WPF / Silverlight."

Sì, ma se non è possibile modificare il progetto principale (ad esempio Orchard CMS), è possibile mantenere la configurazione del servizio WCF nel progetto.

È necessario creare un supporto di servizio con il metodo di generazione 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;
    }
}

e usalo:

using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
                ... get data from service ...
            }

Vedi i dettagli in questo articolo .

Diverse risposte qui colpiscono la soluzione corretta quando ci si trova di fronte all'errore oscuramente insensato di fare riferimento al servizio da un file di classe: copiare le informazioni di configurazione del servizio nel proprio app.config web.config della console o dell'app di Windows. Nessuna di queste risposte sembra mostrarti cosa copiare. Proviamo a correggerlo.

Ecco cosa ho copiato dal file di configurazione della mia libreria di classi, nel file di configurazione dell'app della mia console, al fine di aggirare questo folle errore per un servizio che scrivo chiamato "TranslationServiceOutbound".

Fondamentalmente vuoi tutto nella sezione 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>

Questo mi ha fatto impazzire.

Sto usando Silverlight 3 Prism (CAB) con WCF

Quando chiamo un servizio WCF in un modulo Prism, ottengo lo stesso errore:

Impossibile trovare l'elemento endpoint predefinito che fa riferimento al contratto "IMyService" nella sezione di configurazione del client del modello di servizio. Ciò può essere dovuto al fatto che non è stato trovato alcun file di configurazione per l'applicazione o perché non è stato trovato alcun elemento endpoint corrispondente a questo contratto nell'elemento client

Si scopre che sta cercando nel file .xap della Shell un file ServiceReferences.ClientConfig, non nel file ServiceReferences.ClientConfig del modulo. Ho aggiunto il mio endpoint e il collegamento al file ServiceReferences.ClientConfig esistente nella mia applicazione Silverlight Shell (chiama i propri servizi WCF).

Quindi ho dovuto ricostruire l'app Shell per generare il nuovo file .xap per la cartella ClientBin del mio progetto Web.

Ora questa riga di codice finalmente funziona:

MyServiceClient myService = new MyServiceClient();

Stavo ottenendo questo errore all'interno di un'applicazione ASP.NET in cui il servizio WCF era stato aggiunto a una libreria di classi che veniva aggiunta all'applicazione ASP.NET come file .dll di riferimento nella cartella bin. Per risolvere l'errore, è necessario copiare le impostazioni di configurazione nel file app.config all'interno della libreria di classi che fa riferimento al servizio WCF nelle impostazioni web.config per il sito / app ASP.NET.

Ho trovato (oltre a copiare sull'App.config dell'interfaccia utente del client mentre stavo usando un'interfaccia Libreria di classi) ho dovuto aggiungere il nome dell'associazione con il nome del riferimento di servizio (il mio è ServiceReferencenel seguito).

per esempio:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ServiceReference.ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

invece del predefinito generato:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

Ho avuto lo stesso problema, ma cambiare lo spazio dei nomi del contratto non ha funzionato per me. Così ho provato un riferimento web in stile .Net 2 anziché un riferimento al servizio .Net 3.5. Ha funzionato

Per utilizzare un riferimento Web in Visual Studio 2008, fare clic su "Aggiungi riferimento al servizio", quindi fare clic su "Avanzate" quando viene visualizzata la finestra di dialogo. In questo troverai un'opzione che ti permetterà di usare un riferimento Web invece di un riferimento al servizio.

L'unità che verifica un'applicazione non di libreria che utilizza un servizio può causare questo problema.

Le informazioni che altri hanno inserito affrontano la causa principale di ciò. Se si sta tentando di scrivere casi di test automatizzati e l'unità che si sta testando invocherà effettivamente l'interfaccia di servizio, è necessario aggiungere il riferimento del servizio al progetto di test. Questo è un aspetto dell'applicazione che utilizza il tipo di errore della libreria. Non me ne sono reso conto immediatamente, però, perché il mio codice che utilizza l'interfaccia non si trova in una libreria . Tuttavia, quando il test viene effettivamente eseguito, verrà eseguito dal gruppo test, non dal gruppo testato.

L'aggiunta di un riferimento di servizio al progetto di unit test ha risolto il mio problema.

Ho una situazione che nel test unitario. Ho copiato il file app.config nel progetto di unit test. Quindi il progetto unit test contiene anche informazioni sull'endpoint.

Ho affrontato questo problema una volta. Era perché stavo ancora sviluppando l'interfaccia che utilizza il servizio WCF. Ho configurato l'applicazione di test e lo sviluppo continuo. Quindi in fase di sviluppo, ho modificato alcuni spazi dei nomi dei servizi. Quindi ho ricontrollato "system.serviceModel -> client -> endpoint -> contratto" in web.config per abbinare la classe WCF. Quindi il problema è risolto.

Lo spazio dei nomi nella configurazione deve riflettere il resto del percorso dello spazio dei nomi dopo lo spazio dei nomi predefinito del client (come configurato nelle proprietà del progetto). Sulla base della tua risposta pubblicata, suppongo che il tuo client sia configurato per essere nello spazio dei nomi "Fusion.DataExchange.Workflows". Se si sposta il codice client in un altro spazio dei nomi, è necessario aggiornare la configurazione in modo che corrisponda al percorso rimanente dello spazio dei nomi.

Ho lo stesso problema. Ho usato il servizio WCF nella libreria di classi e ho chiamato la libreria di classi dall'applicazione Windows project.b Ma dimentico il cambiamento <system.serviceModel>nel file di configurazione dell'applicazione Windows <system.serviceModel>Proietti lo stesso del file app.Config della libreria di classi.
soluzione: modifica della configurazione del progetto esterno stessa della configurazione wcf della libreria di classi.

Ciao, ho riscontrato lo stesso problema, ma la soluzione migliore è consentire a .NET di configurare la configurazione lato client. Quello che scopro è questo quando aggiungo un riferimento di servizio con una stringa di query di http: /namespace/service.svc? Wsdl = wsdl0 NON crea un endpoint di configurazione sul lato client. Ma quando rimuovo? Wsdl-wsdl0 e utilizzo solo l'URL http: /namespace/service.svc, crea la configurazione dell'endpoint nel file di configurazione del client. in breve, rimuovere "? WSDL = WSDL0".

Non inserire la riga di dichiarazione del client di servizio come campo di classe, anziché creare questa istanza in ciascun metodo utilizzato in. Quindi il problema verrà risolto. Se si crea l'istanza del client di servizio come campo di classe, si verifica un errore in fase di progettazione!

Nel caso in cui si utilizzi l'applicazione WPF utilizzando il framework PRISM, la configurazione dovrebbe esistere nel progetto di avvio (ovvero nel progetto in cui risiede il bootstrapper.)

Questo errore può verificarsi se si chiama il servizio in una libreria di classi e si chiama la libreria di classi da un altro progetto.

Sembra che ci siano diversi modi per creare / risolvere questo problema. Per me, il prodotto CRM che sto usando è stato scritto in codice nativo ed è in grado di chiamare la mia dll .NET, ma mi imbatto nelle informazioni di configurazione che devono essere in / sopra l'applicazione principale. Per me, l'applicazione CRM non è .NET, quindi ho dovuto metterlo nel mio file machine.config (non dove lo voglio). Inoltre, poiché la mia azienda utilizza Websense, ho avuto difficoltà persino ad aggiungere il riferimento al servizio a causa di un problema 407 di autenticazione proxy, che ha richiesto una modifica a machine.cong.

Soluzione proxy:

Per far funzionare il riferimento al servizio WCF ho dovuto copiare le informazioni dal file app.config della mia DLL nella configurazione dell'applicazione principale (ma per me era machine.config). E ho anche dovuto copiare le informazioni sull'endpoint nello stesso file. Una volta l'ho fatto iniziando a lavorare per me.

Ok. Il mio caso era un po 'diverso ma alla fine ho trovato la soluzione: ho un Console.EXE -> DLL -> Invoking WS1 -> DLL -> Invoking WS2

Ho avuto entrambe le configurazioni del modello di servizio di WS1 e WS2 in Console.EXE.config come raccomandato. - non ha risolto il problema.

Ma non ha ancora funzionato, fino a quando non ho aggiunto anche WebReference di WS2 a WS1 e non solo alla DLL che ha effettivamente creato e richiamato il proxy di WS2.

Se si fa riferimento al servizio Web nella libreria di classi, è necessario copiare app.config nell'applicazione Windows o nell'applicazione console

soluzione: modifica della configurazione del progetto esterno stessa della configurazione wcf della libreria di classi.

Ha funzionato per me

Ho avuto lo stesso problema
che stavo usando l'app desktop e utilizzando il servizio Web Global Weather

Ho eliminato il riferimento al servizio e aggiunto il riferimento web e il problema risolto Grazie

La soluzione per me è stata quella di rimuovere il nome dell'endpoint dall'attributo Nome endpoint nel client web.config, ciò ha permesso al proxy di utilizzare

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

ci è voluto solo tutto il giorno per allenarsi. Inoltre, il nome del contratto era errato una volta che questa correzione era in atto, sebbene fosse stata errata quando è apparso l'errore iniziale. Raddoppia quindi controlla tre volte per le stringhe di nomi di contratto !! attrib: Ian

Consentimi di aggiungere un'altra cosa da cercare. ( Tom Haigh's risposta di allude già ad esso, ma voglio essere esplicito)

Il mio web.configfile aveva il seguente definito:

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

Stavo già usando basicHttpsBinding per un riferimento, ma poi ho aggiunto un nuovo riferimento che richiedeva basicHttpBinding (no). Tutto quello che dovevo fare era aggiungerlo al mio protocolMappingcome segue:

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

Come sottolinea correttamente LR , questo deve essere definito nei posti giusti. Per me ciò significava uno nel file app.config del mio progetto Unit Test e uno nel web.config del progetto di servizio principale.

Ho riscontrato questo errore quando facevo riferimento al contratto nell'elemento del file di configurazione senza l'operatore dell'ambito globale.

vale a dire

<endpoint contract="global::MyNamepsace.IMyContract" .../>

funziona, ma

<endpoint contract="MyNamepsace.IMyContract" .../>

fornisce l'errore "Impossibile trovare l'elemento endpoint predefinito che fa riferimento al contratto".

L'assembly contenente MyNamepsace.IMyContract si trova in un assembly diverso dall'applicazione principale, quindi ciò potrebbe spiegare la necessità di utilizzare la risoluzione globale dell'ambito.

Quando si aggiunge un riferimento al servizio

fai attenzione allo spazio dei nomi che stai digitando:

Dovresti aggiungerlo al nome della tua interfaccia:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" 
            contract="MyNamespace.IMySOAPWebService" />
</client>

Ho avuto lo stesso errore e ho provato molte cose ma non ha funzionato, quindi ho notato che il mio "contratto" non era lo stesso in tutti i progetti, ho modificato il contratto come sarebbe stato lo stesso per tutti i progetti all'interno della soluzione e di quanto ha funzionato. Questo è il progetto A

<client>
    <endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>

Progetto B:

<client>
    <endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>

Alla fine ho cambiato per entrambi come:

<client>
    <endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>

Ho avuto lo stesso problema ed è stato risolto solo quando l'applicazione host e la dll che utilizzavano quell'endpoint avevano lo stesso nome di riferimento del servizio.