WCF: Dienst startet nicht - keine Anwendungsendpunkte

Ich muss mir mal kurz ein paar Augen leihen ...

Die Fehlermeldung lautet:> Fehlermeldung:

Der Dienst kann nicht gestartet werden. System.InvalidOperationException: Der Dienst "Qm_Wcf.QmWcf" verfügt über keine Anwendungsendpunkte (keine Infrastrukturendpunkte). Dies kann folgende Ursachen haben: Es wurde keine Konfigurationsdatei für die Anwendung gefunden, in der Konfigurationsdatei wurde kein mit dem Dienstnamen übereinstimmendes Dienstelement gefunden oder im Dienstelement wurden keine Endpunkte definiert.

Und in der App.config steht folgendes:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  
  <appSettings>
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" />
  </system.web>
 
  <!-- Bei der Bereitstellung des Dienstbibliothekprojekts muss der Inhalt der Konfigurationsdatei der app.config-Datei 
  des Hosts hinzugefügt werden. System.Configuration unterstützt keine Konfigurationsdateien für Bibliotheken. -->
  <system.serviceModel>
    <services>
      <service name="Qm_Wcf.QmWcf">
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8080/qm-wcf/" />
          </baseAddresses>
        </host>
        <endpoint address="" binding="basicHttpBinding" contract="Qm_Wcf.IQmWcf">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- Legen Sie die Werte unten vor der Bereitstellung 
          auf "false" fest, um die Veröffentlichung von Metadateninformationen zu vermeiden. -->
          <serviceMetadata httpGetEnabled="True" httpsGetEnabled="False" />
          <!-- Damit in Fehlern Ausnahmedetails zum Debuggen angezeigt werden, 
          legen Sie den Wert unten auf "true" fest. Legen Sie ihn vor der Bereitstellung auf "false" fest, 
          um die Veröffentlichung von Ausnahmeinformationen zu vermeiden. -->
          <serviceDebug includeExceptionDetailInFaults="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
  
  
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

Sieht einer den Fehler? Ich bin hoffentlich einfach nur blind. Das die App.config an der richtigen Stelle liegt zeigt mir mein DemoProjekt und das hatten wir hier auch schon geklärt.

Hallo irgendwas,

wird der Service nun im IIS od. "standalone" gehostet?
Stimmen die Typ-Angaben in der config mit jenen vom Code überein?

BTW: ab .net 4.0 kannst du dir einen Großteil dieser Konfiguration sparen und somit auch die einhergehenden Probleme. Siehe A Developer's Introduction to Windows Communication Foundation 4.

Wie vorhin schon erwähnt häng das Projekt an, denn nur die Konfig ist bei WCF die halbe Miete. Es gehören auch die Implementierungen dazu.

mfG Gü

Hallo,

der Service läuft Stand-Alone. Ich hatte gedacht das wird deutlich an dem

 <startup>
         <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
     </startup>

Absatz in der Konfig. Sorry.

Was meinst Du jetzt mit den Typ-Angaben? Wenn Du die Bezeichnungen von Interface, Klasse und ServiceHost(typeof(Klasse)) meinst, dann ja.

Allerdings wirft der Link bei mir die Frage auf, ob ich nicht einfach die blöde Konfig aufgebe und die Endpoints und das Zeug einfach im Code deklariere.

Ich räume später das Projekt mal um einen Haufen ungenutztes Zeug auf und hänge das gerne an.

Hallo irgendwas,

nicht einfach die blöde Konfig aufgebe und die Endpoints und das Zeug einfach im Code deklariere.

Ist nicht nötig. Die Standard-Konfig, welche ab .net 4.0 WCF verwendet, deckt auch deinen Fall ab und somit brauchst du in der Konfig keine Endpunkte definieren. Im Code reicht eine Angabe der Endpunkt-Adressen, den Rest übernimmt wieder WCF. Das ist eine erhebliche Erleichterung.

Aber auch ab .net 4.0 muss für das Tracing etwas in die Konfig. geschrieben werden...

mfG Gü

Hallo,

anbei nun das Projekt. Kennwort ging Dir per PN zu.

Schöne Grüße und vielen Dank soweit.

P.S.: Da es scheinbar etwas falsch rübergekommen ist.
Das Kennwort für das Archiv ist Pass!4.prog . Es geht mir nicht darum, dass das der Code vll. gelesen wird, sondern ich stehe nicht so auf automatische Indexierung.

Hallo irgendwas,

ich hab mir das Projekt angeschaut. Statt dem Kennwortschutz vom Archiv wäre es besser gewesen eine abgespeckte und auf das Nötigste reduzierte Version anzuhängen. Durch das Kennwort verwehrst du eben anderen Helfern die Möglichkeit dir zu helfen.

So zum Problem:
Eine app.config bei einer DLL bringt ohne besondere Vorkehrungen nichts, das "app" steht für "application", daher gehört die app.config auch zur EXE bzw. exakter zu jener EXE-Assembly die den Einstiegspunkt der Anwendung hat. In deinem Beispiel also zum Projekt "Qm-Service".

Sonst noch ein paar kleine Tipps:*Wenn du in mehreren Projekten die gleiche app.config od. sonst eine Datei (wie z.B. Versionshinweise) haben willst, so kannst du die Dateien per Link einbinden. Siehe hierzu auch Linked Files in Visual Studio Solutions.

*Wenn du nur managed Komponenten hast, wie es hier im WCF-Teil der Fall ist, so implementiere keine Finalizer. Konkret: ~QmServiceWcfServer kannst du dir sparen. Das ist sogar kontraproduktiv aus Sicht vom Garbage Collector.

Bei einem Windows-Service erleichtert sich das Debuggen wenn der eigentliche "Service-Ausführungs-Code" in eine eigene Assembly gepackt wird (das kann auch eine Konsolen-EXE sein) und der Service dann diesen Code aufruft. Eine separate Konsolen-EXE (od. die gleiche wenn das Projekt wie in der letzten Klammer erwähnt bereits eine EXE ist) kann dann zum Debuggen in VS verwendet werden.

*Schau dir auch Guidelines for Names an.

* in .net kann eine EXE auch eine andere EXE referenzieren, alles sind ja Assemblies.

mfG Gü

Hallo,

erstmal vielen Dank für den Tip mit dem Finalizer.

Der Grund, warum ich bisher keine Miniversion hochgeladen habe ist der, dass diese bei mir funktioniert, die richtige jedoch nicht. Ich kann den Unterschied der Aufrufe zwischen den Versionen jedoch nicht erkennen. Für mich sind sie vom Prinzip her gleich.

Ich habe jetzt den QmServiceWcfService für Debug-Zwecke wie von Dir vorgeschlagen zu einer Konsolenanwendung gemacht und dem die gleiche App.config spendiert. Das funktioniert wie erwartet.

Wenn ich jetzt allerdings versuche den tatsächlichen Service zu starten, bekomme ich immer noch die gleiche Fehlermeldung.

Ich nehme richtig an, dass Qm-Service bzw. der damit erzeugte QmServiceWcfServer die App.config von Qm-Service nutzt und nicht die des QmServiceWcfServer? Generell wäre es sogar egal, da mittlerweile in beiden die Informationen für den WcfService drinstehen.

Was übersehe ich?

Schöne Grüße

Hallo irgendwas,

ich denke jetzt verstehe ich warum die überhaupt diesen config-Inhalt hast. Du hast du das WCF-Projekt anhand der VS-Vorlage "WCF Service Library" erstellt. Korrekt?

Den hab ich vorher nie benutzt, daher kannte ich dessen Eigenheiten auch nicht. (Wieder was dazu gelernt, das ist das Schöne am Forum.

Hallo,

vielen Dank für Deine Mühe. Leider löst es das eigentliche Problem noch nicht.

Damit bekomme ich zwar die Fehlermeldung im Debugger weg - meine Fehlermeldung ist jedoch eine andere.
Der hier geschilderte und behobene Fehler resultiert in einer AddressAlreadyInUseException.
Ich wusste nicht, wie ich das beim Debuggen vermeide, hatte das dann aber für mich dadurch umgangen, dass ich einfach den kompilierten Prozess gestartet und mich anschließend mit Studio als Debugger drangehängt habe. So ist es jedenfalls viel besser. Danke schon einmal dafür. 🙂

Der Fehler der für mich aber einen Blocker darstellt ist:> Fehlermeldung:

Der Dienst kann nicht gestartet werden. System.InvalidOperationException: Der Dienst "Qm_Wcf.QmWcf" verfügt über keine Anwendungsendpunkte (keine Infrastrukturendpunkte). Dies kann folgende Ursachen haben: Es wurde keine Konfigurationsdatei für die Anwendung gefunden, in der Konfigurationsdatei wurde kein mit dem Dienstnamen übereinstimmendes Dienstelement gefunden oder im Dienstelement wurden keine Endpunkte definiert.

Den bekomme ich, wenn ich den QmService ausführe - und nicht den "Debug" WcfServer. Und das, obwohl der QmService über die Anwendungsendpunkte in seiner App.config verfügt.

Hallo irgendwas,

diesen Fehler konnte ich nicht reproduzieren, dass es ein anderer ist bemerkte ich schon.
Da ich mir deinen Service nicht installieren wollte, hab ich den Windows-Service ein wenig umgebogen, so dass eigentlich das Gleiche ausgeführt werden sollte. Dieses Projekt hab ich angehängt (gleiches Kennwort wie von dir).

Schmeiß die WCF-Service-Konfig aus der app.config und setzte den Endpunkt wie in A Developer's Introduction to Windows Communication Foundation 4 Abschnitt Default Endpoints beschrieben.

Wenn meine Projekt-Variante bei dir läuft, das Live-Projekt aber nicht, so kannst du auch nach [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden vorgehen.

mfG Gü

Hallo,

ich hab's gerade mal ausprobiert und bekomme den Fehler tatsächlich auch nur, wenn ich den Service wirklich installiere und ausführe. So ein Quark. Naja, ich habe jetzt fürs Debugging einen Extraeinstieg mit App.config und Logfile geschaffen und prügel jetzt die Endpunkte direkt via Code in den Service.

Ist zwar nicht wirklich Sinn der Sache, aber so kann ich wenigstens weiterarbeiten.

Vielen Dank an alle. Falls irgendwer die Hintergründe einmal wirklich beleuchten kann die zu diesem Verhalten führen, wäre ich zwar nicht undankbar, denn ich verstehe meine Fehler gerne, aber es ist nicht mehr zwingend nötig.

Nochmals vielen Dank für die Mühe und insbesondere die Abhilfe!