Laden...

WCF: Dienst startet nicht - keine Anwendungsendpunkte

Letzter Beitrag vor 11 Jahren 11 Posts 7.096 Views
Hinweis von gfoidl vor 11 Jahren

Abgeteilt von WCF - trotz system.diagnostics etc keine Logfile

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.

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++

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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

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.

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++

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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

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.

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++

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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

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

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++

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.

Seitens MS finde ich die Sache mit der app.config etwas inkonsequent - einerseits gibts die erleichterte Konfig. ab .net 4.0 und dann sind alle möglichen Werte dennoch wieder in der app.config - aber das lässt sich durch Anpassen der Vorlage ja ändern od. eben die Vorlage gar nicht verwenden. Ich erstelle die WCF-Projekte eigentlich immer so:1.erstell ein Klassenbibliotheks-Projekt 1.füge den Verweis für System.ServiceModel hinzu 1.erstell die Service-Schnittstelle (ServiceContract) 1.erstell die Implementierung 1.(optional) für Tracing: füge eine app.config zum Host-Projekt des WCF-Services hinzu und in der app.config den passenden system.diagnostics-Abschnitt

Bei dir erscheint mir die Solution (ich hab mir nur den WCF-Teil angeschaut) etwas "wirr" und unnötig kompliziert. Das kannst du auch viel einfacher gestalten. Such mal im Forum, da gibts sicher ein WCF-Beispiel von mir, wo das einfacher und direkter erledigt wird.
Z.B. ist die OnCustomCommand-Methode in QmServiceManager nicht nötig - schreib den Inhalt vom switch-Statement doch direkt in die jeweilige Methode.

Zurück zum Problem: Bei mir war die Ursache eine Eigenheit dieses speziellen Projekt-Types, eigentlich eher eine Gemeinheit 😉
Bei diesem Projekt-Typ gibt es in den Projekt-Eigenschaften einen neuen Reiter "WCF Options" und dort findet sich der Haken an der Sache, da "Start WCF Service Host when debugging another project in the same solution" angehakt ist. D.h. beim Debuggen wird für dieses Projekt von VS automatisch ein Service-Host gestartet (ersichtlich am Notification-Baloon in der Taskleiste) und wenn dann der eigene Service-Host mit der gleichen config und somit gleichen Endpunkt-Adresse starten will kommt es zur Kollision. Daher weg mit diesem Haken und gut ist es (zumindest bei meiner Kopie deines Projektes 😃).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

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.

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++

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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

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!

++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++