2010-07-06 36 views
12

Scusate per la dichiarazione del problema lungo ... Ho passato due giorni di debug e hanno un sacco di note ..."Impossibile trovare elemento endpoint con nome ..."

Ho un servizio dati WCF e un altro processo che tenta di connettersi ad esso come client tramite TCP e/o HTTP.

Ho un'app client di test MOLTO semplice che sembra connettersi bene, ma l'app di produzione più complicata non può connettersi (né TCP né HTTP). In entrambi i progetti client, ho permesso a Visual Studio 2008 di generare app.config utilizzando "Aggiungi riferimento servizio" e consentendogli di estrarre i metadati dal servizio dati.

ecco il codice per il semplice client di prova che funziona:

using Client.MyDataService; 

namespace Client 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      MyDataServiceClient client = new MyDataServiceClient("net.tcp"); 

      client.GetRecords(); 
     } 
    } 
} 

Ecco il codice per il più complicato, client di produzione:

DataServiceManager.cs:

using MyServer.MyDataService; 

namespace MyServer.DataServiceBridge 
{ 
    class DataServiceManager 
    { 
     MyDataServiceClient dataServiceClient = new MyDataServiceClient("net.tcp"); 
} 
} 

Nel processo principale:

DataServiceManager d = new DataServiceManager(); 

Ecco il file app.config sia per il semplice client cliente e la produzione:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <system.serviceModel> 
     <bindings> 
      <netTcpBinding> 
       <binding name="net.tcp" closeTimeout="00:01:00" openTimeout="00:01:00" 
        receiveTimeout="00:10:00" sendTimeout="00:01:00" transactionFlow="false" 
        transferMode="Buffered" transactionProtocol="OleTransactions" 
        hostNameComparisonMode="StrongWildcard" listenBacklog="10" 
        maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="10" 
        maxReceivedMessageSize="65536"> 
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
         maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
        <reliableSession ordered="true" inactivityTimeout="00:10:00" 
         enabled="false" /> 
        <security mode="Transport"> 
         <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" /> 
         <message clientCredentialType="Windows" /> 
        </security> 
       </binding> 
      </netTcpBinding> 
     </bindings> 
     <client> 
      <endpoint address="net.tcp://localhost:8888/MyDataService" 
       binding="netTcpBinding" bindingConfiguration="net.tcp" contract="MyDataService.IMyDataService" 
       name="net.tcp"> 
       <identity> 
        <userPrincipalName value="COMPUTER_NAME\Username" /> 
       </identity> 
      </endpoint> 
     </client> 
    </system.serviceModel> 
</configuration> 
  • In Debug \ bin \ di MyServer è MyServer.exe, app.config.

  • In bin \ Debug del MyDataSeriviceHost \ cartella è MyDataService.exe, app.config e MyDataSeriviceHost.exe.config. app.config e MyDataSeriviceHost.exe.config sono identici.

Ecco il messaggio di errore:

An exception of type 'System.InvalidOperationException' occurred in System.ServiceModel.dll but 
was not handled in user code 

Additional information: Could not find endpoint element with name 'net.tcp' and contract 
'MyDataService.IMyDataService' in the ServiceModel client configuration section. 
This might be because no configuration file was found for your application, or because no endpoint 
element matching this name could be found in the client element. 

Tutte le idee che cosa sta succedendo? Ho praticamente esaurito Google. :-(

+1

Probabilmente un errore di battitura, ma il vostro errore messaggio legge: IyDataService. Probabilmente dovrebbe essere IMyDataService. –

+0

Sì, quello era un refuso nella redazione per postare qui. Risolto, grazie! – CrypticPrime

+0

per favore non duplicare tag come "WCF" nel titolo. Ecco a cosa servono i tag. –

risposta

18

RISOLTO

Si scopre che abbiamo un exe che carica una DLL. la DLL contiene il WCF client Quando viene compilato, MyServer.dll.config viene generato, ma poiché l'exe è nativo (non .NET) non viene letto automaticamente in un file .config. È necessario eseguirlo manualmente. T il suo collegamento mi ha permesso di caricare manualmente la configurazione e creare una CustomChannelFactory <> per risolvere questa domanda.

Per chiunque altro che necessitano la stessa cosa, ecco il link che ha portato alla soluzione: http://www.paraesthesia.com/archive/2008/11/26/reading-wcf-configuration-from-a-custom-location.aspx

3

Potrebbe essere il modo in cui l'hai scritto, ma sembra che il tuo file di configurazione non venga copiato correttamente nella directory. Dovrebbe avere un nome corrispondente alla tua applicazione non app.config. Se provi a cambiare il nome del file app.config per [il tuo nome exe] exe.config fa questo aiuto.

+0

Ho provato anche quello. Non funziona. Sia app.config che MyServer.exe.config sono lì dentro (e ho provato a rimuovere uno o l'altro anche solo per i calci). – CrypticPrime

+0

Beh, solo per riferimento futuro, app.config non funzionerà mai perché non verrà prelevato.Quindi entrambe le applicazioni hanno il file .config lì con il nome corrispondente al nome del file exe corrente. Hai forse copiato la configurazione dalla semplice app nell'app complessa e hai dimenticato di cambiare il nome della configurazione? – spinon

+0

Purtroppo, vorrei che fosse così. Tutti i nomi dei file sono corretti. – CrypticPrime

5

ho avuto una situazione come questa, in cui ho avuto

  • WCF servizio in hosting da qualche parte
  • Progetto principale
  • Progetto consumer di tipo 'class Library' con riferimento al servizio WCF
  • Proj principale ect chiama i metodi di progetto consumatore

Ora il progetto dei consumatori aveva tutte le impostazioni di configurazione relative a <system.serviceModel> Tag del mio app.config, la sua è stata ancora gettando lo stesso errore come sopra.

Tutto ciò che ho fatto è stato aggiunto lo stesso tag <system.serviceModel> al file app.config del mio progetto principale, e alla fine siamo andati bene.

Il problema reale, per quanto nel mio caso era, stava leggendo il file di configurazione sbagliato. Invece dell'app.config del consumatore, si riferiva alla configurazione principale del proj. mi ci sono volute due ore per capirlo.

1

Quando l'EXE consuma la DLL, il file di configurazione che cerca non è DLLName.Dll.Config suo EXEName.exe.config, cambia il nome del file di configurazione generato e lo copia nel percorso di esecuzione. Dovrebbe funzionare.

Cheers !!!!!!!!!

0

Una situazione simile con una soluzione diversa, che può essere utile in queste circostanze particolari:

  • Come i posti di cui sopra, ho un file EXE che ospita client definito nella DLL.

  • diverso da situazione di cui sopra è che il mio cliente sta usando la sonda UDP per scoprire endpoint del servizio (ovviamente il servizio ha permesso MEX)

Il Clientproxy eredita DuplexClientBase, e il metodo di istanza di overload consente di specificare vincolante e endpoint senza richiedere alcun file di configurazione.

un VB esempio, ho scoperto un endpoint (EP) e so che l'associazione è TCP con la sicurezza disabilitata, così posso istanziare e usare client callback come:

myClientProxy = New ClientProxy(New InstanceContext(Me), New NetTcpBinding(SecurityMode.None), ep.Address) 
Problemi correlati