Der Dienst verfügt über keine Anwendungsendpunkte (ohne Infrastruktur)

Ich habe kürzlich einen WCF-Dienst (DLL) und einen Diensthost (Exe) erstellt. Ich weiß, dass mein WCF-Dienst ordnungsgemäß funktioniert, da ich den Dienst erfolgreich zu WcfTestClient hinzufügen kann.

Es scheint jedoch, dass ich auf ein Problem stoße, wenn ich meine WCF von einem Service-Host (exe) aus verwende. Ich kann meinem Service-Host (exe) einen Verweis auf die WCF (dll) hinzufügen und die erforderlichen Komponenten für die exe erstellen. Kompilieren Sie die Exe und installieren Sie sie schließlich mithilfe von InstallUtil, z. B. das Service-Installationsprogramm, den Service-Host und die app.config. Als ich jedoch versuchte, den Dienst in der Microsoft Management Console zu starten, wird der Dienst sofort nach dem Start beendet.

Also begann ich zu untersuchen, was genau dieses Problem verursachen könnte, und stellte diesen Fehler im Anwendungsprotokoll in der Ereignisanzeige fest.

Beschreibung:

Der Dienst kann nicht gestartet werden. System.InvalidOperationException: Der Dienst 'Service' hat keine Anwendungsendpunkte (ohne Infrastruktur). Dies kann daran liegen, dass für Ihre Anwendung keine Konfigurationsdatei gefunden wurde oder dass in der Konfigurationsdatei kein mit dem Dienstnamen übereinstimmendes Dienstelement gefunden wurde oder dass im Dienstelement keine Endpunkte definiert wurden.

Dieser Fehler wird tatsächlich in der generiert OnStart; von meiner Exe, wenn ich diesen Anruf durchführe ServiceHost.Open(). Ich habe zahlreiche Posts gesehen, in denen andere Personen auf dieses Problem gestoßen sind. Die meisten, wenn nicht alle, behaupten jedoch, dass der Name oder der Vertrag des Dienstes angegeben ist. Namespace und Klassenname werden nicht angegeben. Ich habe diese beiden Einträge in meiner Konfigurationsdatei überprüft. sowohl in der exe als auch in der dll, und sie passen perfekt zusammen. Ich habe andere Leute im Büro hinter mir überprüfen lassen, um sicherzustellen, dass ich nicht irgendwann blind wurde, aber sie kamen natürlich zu dem gleichen Schluss wie ich, dass alles so aussah, als wäre es korrekt angegeben. Ich bin wirklich ratlos darüber, was zu diesem Zeitpunkt los ist. Könnte mir jemand bei diesem Problem helfen?

Ein weiterer möglicher Grund dafür ist, dass die app.config nie gelesen wird. Zumindest nicht der, von dem ich denke, dass er gelesen werden sollte. Könnte dies das Problem sein? Wenn ja, wie kann ich dieses Problem beheben? Auch hier wäre jede Hilfe dankbar.

Ich hatte gerade dieses Problem und löste es, indem ich den Namespace zum Dienstnamen hinzufügte, z

 <service name="TechResponse">

wurden

 <service name="SvcClient.TechResponse">

Ich habe auch gesehen, dass es mit einer Web.config anstelle einer App.config gelöst wurde.

Der Endpunkt sollte auch den Namespace haben:

 <endpoint address="uri" binding="wsHttpBinding" contract="Namespace.Interface" />

Eine Sache, über die Sie nachdenken sollten, ist: Haben Sie Ihre WCF vollständig vom WindowsService (WS) abgekoppelt? Ein WS ist schmerzhaft, weil Sie nicht viel Kontrolle oder Sichtbarkeit für sie haben. Ich versuche dies zu mildern, indem ich alle meine Nicht-WS-Sachen in ihren eigenen Klassen habe, damit sie unabhängig vom Host-WS getestet werden können. Die Verwendung dieses Ansatzes kann Ihnen dabei helfen, alles zu beseitigen, was mit der WS-Laufzeit im Vergleich zu Ihrem Dienst passiert.

John hat wahrscheinlich Recht, dass es sich um ein Problem mit der .config-Datei handelt. WCF sucht immer nach dem Ausführungskontext .config . Wenn Sie Ihre WCF also in verschiedenen Ausführungskontexten hosten (dh mit einer Konsolenanwendung testen und mit einem WS bereitstellen), müssen Sie sicherstellen, dass die WCF-Konfigurationsdaten in die richtige .config-Datei verschoben wurden. Aber das zugrunde liegende Problem für mich ist, dass Sie nicht wissen, was das Problem ist, weil die WS-Gänsehaut im Weg ist. Wenn Sie dies noch nicht überarbeitet haben, damit Sie Ihren Dienst in einem beliebigen Kontext (dh Unit-Test oder Konsole) ausführen können, würde ich dies empfehlen. Wenn Sie Ihren Dienst in einem Komponententest hochfahren, schlägt dies wahrscheinlich genauso fehl wie beim WS, was viel einfacher zu debuggen ist, als dies mit dem glücklichen WS-Sanitär zu versuchen.

Kopieren Sie einfach die Datei App.config aus dem Dienstprojekt in die Konsolenhostanwendung, fügen Sie sie hier ein und löschen Sie sie aus dem Dienstprojekt.

Ich habe eine detailliertere Ausnahme erhalten, als ich sie programmgesteuert hinzugefügt habe - AddServiceEndpoint:

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

Die Vorbereitung der Konfigration auf WCF ist schwierig, und manchmal bleibt eine Definition des Diensttyps unbemerkt.

Ich habe nur den Namespace in das Service-Tag geschrieben, daher habe ich den gleichen Fehler erhalten.

<service name="ServiceNameSpace">

Vergessen Sie nicht, dass das Service-Tag einen vollständig qualifizierten Serviceklassennamen benötigt.

<service name="ServiceNameSpace.ServiceClass">

Für die anderen Leute, die wie ich sind.

Heute bin ich auf dasselbe Problem gestoßen und habe hier meinen Fehler und seine Korrektur veröffentlicht, damit es jemandem helfen kann.

Während ich den Code neu strukturierte, hatte ich tatsächlich die Namen der Serviceklassen und IServices geändert und ServiceHost geändert, um auf diesen neuen Namen der Serviceklasse zu verweisen (wie im Codefragment gezeigt), aber in der App.Config-Datei meiner Hostanwendungen verwendete ich immer noch den alten Namen der Serviceklasse (siehe Namensfeld des Konfigurationsabschnitts im folgenden Snippet)

Hier ist das Code-Snippet,

 ServiceHost myServiceHost = new ServiceHost(typeof(NewServiceClassName)); 

und in der App.config-Datei unter Abschnitt services bezog ich mich auf den alten Serviceklassennamen und änderte ihn in New ServiceClassName. Das Problem wurde für mich behoben.

  <service name="ProjectName.OldServiceClassName"> 
        <endpoint address="" binding="basicHttpBinding" contract="ProjectName.IService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        <host>
          <baseAddresses>
            <add baseAddress=""/>
          </baseAddresses>
        </host>
      </service>

Ich hatte das gleiche Problem. Alles funktioniert in VS2010, aber wenn ich dasselbe Projekt in VS2008 ausführe, erhalte ich die erwähnte Ausnahme.

In meinem VS2008-Projekt habe ich einen Aufruf an das AddServiceEndpointMitglied meines ServiceHost-Objekts hinzugefügt, damit es funktioniert .

Hier ist mein Code-Snippet:

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

Ich habe die Datei app.config nicht geändert. Aber ich denke, der Service-Endpunkt könnte auch in der .config-Datei hinzugefügt worden sein.

Ich habe dieses Problem gerade in meinem Dienst durchgearbeitet. Hier ist der Fehler, den ich erhalten habe:

Der Dienst 'EmailSender.Wcf.EmailService' hat keine Anwendungsendpunkte (ohne Infrastruktur). Dies kann daran liegen, dass für Ihre Anwendung keine Konfigurationsdatei gefunden wurde oder dass in der Konfigurationsdatei kein mit dem Dienstnamen übereinstimmendes Dienstelement gefunden wurde oder dass im Dienstelement keine Endpunkte definiert wurden.

Hier sind die zwei Schritte, mit denen ich das Problem behoben habe:

1. Verwenden Sie den richtigen vollqualifizierten Klassennamen:

   <service behaviorConfiguration="DefaultBehavior" name="EmailSender.Wcf.EmailService">

2. Aktivieren Sie einen Endpunkt mit mexHttpBinding und verwenden Sie vor allem den IMetadataExchange-Vertrag:

   <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

Dieser Fehler tritt auf, wenn die Konfigurationsdatei der Hosting-Anwendung Ihres WCF-Dienstes nicht die richtige Konfiguration aufweist.

Denken Sie an diesen Kommentar aus der Konfiguration:

Bei der Bereitstellung des Servicebibliotheksprojekts muss der Inhalt der Konfigurationsdatei zur Datei app.config des Hosts hinzugefügt werden. System.Configuration unterstützt keine Konfigurationsdateien für Bibliotheken.

Wenn Sie einen WCF-Dienst in IIS gehostet haben, liest er zur Laufzeit über VS.NET die app.config des Servicebibliotheksprojekts, nach der Bereitstellung jedoch die web.config des Hosts. Wenn web.config nicht die identische <system.serviceModel>Konfiguration hat, wird dieser Fehler angezeigt . Stellen Sie sicher, dass Sie die Konfiguration aus app.config kopieren, sobald sie perfektioniert wurde.

Ich bin gerade auf dieses Problem gestoßen und habe alle oben genannten Antworten überprüft, um sicherzustellen, dass mir nichts Offensichtliches entgangen ist. Nun, ich hatte ein halb offensichtliches Problem. Die Schreibweise meines Klassennamens im Code und des Klassennamens, den ich in der Konfigurationsdatei verwendet habe, stimmten nicht überein.

Beispiel: Wenn der Klassenname CalculatorService lautet und die Konfigurationsdatei auf Calculatorservice verweist, wird dieser Fehler angezeigt.

Ich habe Visual Studio im Administratormodus ausgeführt und es hat bei mir funktioniert :) Stellen Sie außerdem sicher, dass sich die Datei app.config, die Sie zum Schreiben der WCF-Konfiguration verwenden, in dem Projekt befindet, in dem die Klasse "ServiceHost" verwendet wird, und nicht im tatsächlichen WCF-Dienst Projekt.

Mein Problem war, als ich meine Standard-Service1-Klasse für die SVC-Datei in einen aussagekräftigeren Namen umbenannte, was dazu führte, dass die Verhaltenskonfiguration und der Endpunkt von web.config der alten Namenskonvention entsprachen. Versuchen Sie, Ihre web.config zu reparieren.

Für diejenigen, die mit einer Konsolenanwendung arbeiten, um den WCF-Dienst zu hosten, ist es wichtig, dass die Datei Web.config im WCF-Projekt vollständig ignoriert wird. Wenn Ihre system.serviceModelKonfiguration vorhanden ist, müssen Sie diesen Konfigurationsabschnitt in die App.config Ihres Konsolenprojekts verschieben.

Dies gilt zusätzlich zu den Antworten zur Sicherstellung, dass der Namespace an den richtigen Stellen angegeben ist.

Als weiterer Hinweis hat dies dieses Problem in meinem Fall tatsächlich behoben.

Ich migriere einige WCF-Dienste von einer Konsolenanwendung (die nur wenige WCF-Dienste mit Code konfiguriert) zu einer Azure-Webrolle, um sie in Azure zu veröffentlichen. Jedes Mal, wenn ich einen neuen Dienst hinzufüge, bearbeitet VS meine web.config und fügt diese Zeile hinzu:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">

Nun, mit all den oben genannten Ratschlägen und Antworten konnte ich es nicht zum Laufen bringen, bis ich alle Attribute im serviceHostingEnvironment-Element entfernt hatte. Wie Sie sehen, bin ich kein WCF-Rockstar, aber ich habe es geschafft, mit dem ersten Service zu arbeiten, indem ich ihn wie folgt konfiguriert habe:

<service name="FirstService" behaviorConfiguration="metadataBehavior">
                <endpoint address=""
                 binding="wsHttpBinding"
                 bindingConfiguration="WSHttpBinding_WcfServicesBinding"
                 contract="IFirstService" />

            </service>

Aber als ich den zweiten Service hinzufügte, funktionierte er nicht mehr und ich erkannte, dass diese Attribute wieder vorhanden waren.

Ich hoffe es spart dir Zeit.

Ich hatte diesen Fehler in einem Windows-Dienst, als meine von mir erstellte WCF-Dienstbibliothek nicht für das Hosting, sondern für die Verbindung verbunden war. Mir fehlte ein Endpunkt. (Ich wollte sowohl Verbindung als auch Hosting in meinem Windows-Dienst, damit ich den WCF-Dienst für andere Verbindungen bereitstellen und den Hauptprozess meines Windows-Dienstes auch dazu verwenden kann, verschiedene Aufgaben nach einem Timer / Zeitplan auszuführen.)

Das Update war, dass ich mit der rechten Maustaste auf meine App.config-Datei geklickt und WCF-Konfiguration bearbeiten ausgewählt habe. Dann habe ich die Schritte zum Erstellen eines Dienstes ausgeführt, damit ich eine Verbindung zu meinem WCF-Dienst herstellen kann. Jetzt hatte ich zwei Endpunkte in meiner App.config, nicht nur einen. Ein Endpunkt war für die Verbindung zur WCF-Servicebibliothek und ein anderer für das Hosting.