Il servizio ha zero endpoint dell’applicazione (non infrastruttura)

Di recente ho creato un servizio WCF (dll) e un host di servizio (exe). So che il mio servizio WCF funziona correttamente poiché sono in grado di aggiungere correttamente il servizio a WcfTestClient.

Tuttavia, mi sembra che si stia verificando un problema quando si tratta di utlizzare la mia WCF da un host di servizio (exe). Posso aggiungere un riferimento al WCF (dll) al mio host di servizio (exe) e creare i componenti necessari per l’exe; come il programma di installazione del servizio, l’host del servizio e l’app.config, compilare e quindi installare l’exe utilizzando InstallUtil. Tuttavia, quando ho provato ad avviare il servizio in Microsoft Management Console, il servizio si interrompe immediatamente dopo l’avvio.

Così ho iniziato a indagare su cosa poteva essere esattamente la causa di questo problema e ho trovato questo errore nel registro applicazioni nel Visualizzatore eventi.

Descrizione:

Il servizio non può essere avviato. System.InvalidOperationException: il servizio ‘Service’ ha zero endpoint dell’applicazione (non infrastruttura). Ciò potrebbe essere dovuto al fatto che non è stato trovato alcun file di configurazione per l’applicazione o perché non è stato trovato alcun elemento del servizio che corrisponde al nome del servizio nel file di configurazione o perché non sono stati definiti endpoint nell’elemento del servizio.

Questo errore è effettivamente generato OnStart ; del mio exe, quando ServiceHost.Open() questa chiamata ServiceHost.Open() . Ho visto numerosi post in cui altri individui hanno incontrato questo problema, tuttavia la maggior parte se non tutti, sostengono che il nome del servizio o il contratto; spazio dei nomi e nome della class, non vengono specificati. Ho controllato entrambe le voci nel mio file di configurazione; nel exe e nella dll, e si abbinano perfettamente. Ho avuto altre persone in ufficio che controllavano dietro di me per assicurarmi che non sarei diventato cieco a un certo punto, ma ovviamente sono giunti alla stessa conclusione che a me sembrava che tutto fosse come specificato correttamente. Sono veramente perso in quello che sta succedendo a questo punto. Qualcuno potrebbe aiutarmi con questo problema?

Un’altra cosa che è emersa come ansible causa potrebbe essere che app.config non viene mai letto; almeno non quello che penso dovrebbe essere letto. Potrebbe essere questo il problema? In tal caso, come posso risolvere questo problema. Ancora una volta, QUALSIASI aiuto sarebbe apprezzato.

Ho appena avuto questo problema e l’ho risolto aggiungendo lo spazio dei nomi al nome del servizio, ad es

   

divenne

   

Ho anche visto risolto con un web.config invece di un app.config.

L’endpoint dovrebbe avere anche lo spazio dei nomi:

   

Una cosa a cui pensare è: hai il tuo WCF completamente disgiunto dal WindowsService (WS)? Una WS è dolorosa perché non ne hai il controllo o la visibilità. Cerco di mitigarlo avendo tutte le mie cose non WS nelle proprie classi in modo che possano essere testate indipendentemente dal WS host. L’utilizzo di questo approccio potrebbe aiutarti a eliminare tutto ciò che accade con il runtime WS rispetto al tuo servizio in particolare.

È probabile che John corregga il problema relativo al file .config. WCF cercherà sempre il contesto di esecuzione .config . Quindi, se si sta ospitando WCF in diversi contesti di esecuzione (ovvero, test con un’applicazione console e distribuzione con un WS), è necessario assicurarsi che i dati di configurazione di WCF vengano spostati nel file .config appropriato. Ma il problema di fondo per me è che non si sa quale sia il problema perché la WS goo si mette di mezzo. Se non hai ancora effettuato il refactoring in modo che tu possa eseguire il tuo servizio in qualsiasi contesto (cioè, unit test o console), allora suggerirei di farlo. Se fai girare il tuo servizio in un test di unità, probabilmente fallirà nello stesso modo in cui stai vedendo con WS, che è molto più facile da eseguire il debug piuttosto che tentare di farlo con lo Yucky WS Plumbing.

Basta copiare il file App.config dal progetto di servizio all’applicazione host della console e incollarlo qui e quindi cancellarlo dal progetto di servizio.

Ho ricevuto un’eccezione più dettagliata quando l’ho aggiunto a livello di AddServiceEndpointAddServiceEndpoint :

 string baseAddress = "http://" + Environment.MachineName + ":8000/Service"; ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress)); host.AddServiceEndpoint(typeof(MyNamespace.IService), new BasicHttpBinding(), baseAddress); host.Open(); 

Per preparare la configrazione per WCF è difficile, ea volte una definizione del tipo di servizio passa inosservata.

Ho scritto solo lo spazio dei nomi nel tag di servizio, quindi ho ricevuto lo stesso errore.

  

Non dimenticare, il tag di servizio richiede un nome di class di servizio completo.

  

Per le altre persone che sono come me.

Ho avuto lo stesso problema. Tutto funziona in VS2010 ma quando eseguo lo stesso progetto in VS2008 ottengo l’eccezione menzionata.

Quello che ho fatto nel mio progetto VS2008 per farlo funzionare è stato l’aggiunta di una chiamata al membro AddServiceEndpoint del mio object ServiceHost.

Ecco il mio frammento di codice:

 Uri baseAddress = new Uri("http://localhost:8195/v2/SystemCallbackListener"); ServiceHost host = new ServiceHost(typeof(SystemCallbackListenerImpl), baseAddress); host.AddServiceEndpoint(typeof(CsfServiceReference.SystemCallbackListener), new BasicHttpBinding(), baseAddress); host.Open(); 

Non ho modificato il file app.config. Ma suppongo che l’endpoint del servizio potrebbe anche essere stato aggiunto nel file .config.

Ho appena lavorato a questo problema sul mio servizio. Ecco l’errore che stavo ricevendo:

Servizio ‘EmailSender.Wcf.EmailService’ ha zero endpoint dell’applicazione (non infrastruttura). Ciò potrebbe essere dovuto al fatto che non è stato trovato alcun file di configurazione per l’applicazione o perché non è stato trovato alcun elemento del servizio che corrisponde al nome del servizio nel file di configurazione o perché non sono stati definiti endpoint nell’elemento del servizio.

Ecco i due passaggi che ho usato per risolverlo:

  1. Utilizza il nome di class completo e corretto:

      
  2. Abilitare un endpoint con mexHttpBinding e, soprattutto, utilizzare il contratto IMetadataExchange:

      

Il mio problema è stato quando ho rinominato la mia class Service1 predefinita per il file .svc con un nome più significativo, il che ha causato che web.config behaviorConfiguration e endpoint corrispondessero alla vecchia convenzione di denominazione. Prova a correggere il tuo web.config.

Questo errore si verifica se il file di configurazione dell’applicazione di hosting del servizio WCF non ha la configurazione corretta.

Ricorda questo commento dalla configurazione:

Quando si distribuisce il progetto della libreria di servizi, il contenuto del file di configurazione deve essere aggiunto al file app.config dell’host. System.Configuration non supporta i file di configurazione per le librerie.

Se si dispone di un servizio WCF ospitato in IIS, durante il runtime tramite VS.NET, esso leggerà l’app.config del progetto della libreria di servizi, ma leggerà il file web.config dell’host una volta distribuito. Se web.config non ha la configurazione identica, riceverai questo errore. Assicurati di copiare la configurazione da app.config dopo che è stata perfezionata.

Ho appena letto questo problema e ho controllato tutte le risposte di cui sopra per assicurarmi che non mi mancasse nulla di ovvio. Bene, ho avuto un problema semi-ovvio. La mia custodia del mio nome di class nel codice e il nome della class che ho usato nel file di configurazione non corrispondevano.

Ad esempio: se il nome della class è CalculatorService e il file di configurazione fa riferimento a Calculatorservice … si otterrà questo errore.

Ho eseguito Visual Studio in modalità Amministratore e ha funzionato per me 🙂 Inoltre, assicurati che il file app.config che stai utilizzando per scrivere la configurazione di WCF deve essere nel progetto in cui viene utilizzata la class “ServiceHost” e non nel servizio WCF effettivo progetto.

Una cosa fondamentale da ricordare per chi lavora con un’applicazione Console per ospitare il servizio WCF è che il file Web.config nel progetto WCF è completamente ignorato. Se la configurazione system.serviceModel è presente, è necessario spostare tale sezione di configurazione su App.config del progetto Console.

Questo è in aggiunta alle risposte riguardanti l’assicurazione che lo spazio dei nomi sia specificato nei posti giusti.

Come un altro indizio, questo ha effettivamente risolto questo problema nel mio caso.

Sto migrando alcuni servizi WCF da un’applicazione console (che configura nel codice alcuni servizi WCF) a una WebRole di Azure per pubblicarli in Azure. Ogni volta che aggiungo un nuovo servizio, VS modifica il mio web.config e aggiunge questa riga:

  

Bene, con tutti i consigli e le risposte di cui sopra non ho potuto farlo funzionare finché non ho rimosso tutti gli attributi nell’elemento servizioHostingEnvironment. Come puoi vedere non sono una rockstar di WCF ma l’ho fatto per funzionare con il primo servizio semplicemente configurandolo come:

    

ma quando ho aggiunto il secondo servizio ha smesso di funzionare e ho capito che quegli attributi dovevano esserci ancora.

Spero che ti faccia risparmiare tempo.

Ho avuto questo errore in un servizio di Windows quando la mia libreria di servizi WCF che ho creato non era connessa per l’hosting, ma era connessa per la connessione. Mi mancava un endpoint. (Volevo sia la connessione e l’hosting nel mio servizio di Windows in modo che potessi servire il servizio WCF ad altre connessioni, così come il processo principale del mio servizio di Windows usarlo anche per fare varie attività su un timer / programma.)

La soluzione è che ho fatto clic con il tasto destro sul mio file App.config e ho scelto Modifica configurazione WCF. Quindi, ho eseguito i passaggi per creare il servizio in modo che potessi connettermi al servizio WCF. Ora avevo due endpoint nel mio App.config, non solo uno. Un endpoint era per la connessione alla libreria di servizi WCF e un altro era per l’hosting di esso.