Laden...

WCF: in WindowsService hosten

Erstellt von Infowissler vor 12 Jahren Letzter Beitrag vor 12 Jahren 5.589 Views
I
Infowissler Themenstarter:in
27 Beiträge seit 2011
vor 12 Jahren
WCF: in WindowsService hosten

Zu dem Thema gibt es ja eine schöne MSDN-Anleitung: Hosting and Consuming WCF Services

Allerdings bekomme ich da beim Starten des installierten Dienstes den Fehler:

Fehlermeldung:
Der Dienst kann nicht gestartet werden. System.InvalidOperationException: Der Dienst "MeinWCFProjekt.MeineServiceKlasse" 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.

Ich habe in der Web.config schon alle möglichen endpoint Adressen ausprobiert, aber auch beim debuggen interessiert es das Programm überhaupt nicht, ob da jetzt http://localhost:123456 steht oder sonstwas.

Liegt das evtl. daran, dass ich in den Projekteigenschaften meines WCF-Projekts eingestellt habe, dass es den lokalen IIS-Server verwenden soll?
Eigentlich hatte ich das auch so verstanden, dass man den IIS-Server gar nicht mehr braucht, wenn man den WCF-Service in einem Windows Service hostet.
Muss ich evtl. "Benutzerdefinierten WebServer verwenden" anhaken und wenn ja, was muss ich da eintragen?

Im Unterschied zur Anleitung habe ich halt auch nicht den ICalculator-Sample-WCF-Dienst verwendet sondern meinen eigenen, von daher kann es auch gut sein, dass der noch falsch konfiguriert ist, ich weiß nur nicht, wie...

edit: habe jetzt mal alles neu erstellt, mit jungfräulicher Web.Config und Standardeinstellungen bei den Projekteigenschaften, da kommt derselbe Fehler...

edit2: Ich glaub, ich weiß meinen Fehler jetzt: ich habe 2 Projekte, einmal das WCF-Projekt und einmal das Windows Dienst - Projekt und es wird wohl dann nur die app.config des Windows-Dienst-Projekts ausgewertet und ich kann in die web.config vom WCF-Projekt reinschreiben, was ich will, das interessiert gar nicht.
Jetzt muss ich nur noch die endpoint address in die app.config des Windows Dienst-Projekt reinschreiben(?)

C
2.122 Beiträge seit 2010
vor 12 Jahren

Jetzt muss ich nur noch die endpoint address in die app.config des Windows Dienst-Projekt reinschreiben(?)

Würde ich so sehen.
Endpunkte und Behaviour und Binding da rein setzen und es sollte gehen.

I
Infowissler Themenstarter:in
27 Beiträge seit 2011
vor 12 Jahren

Ich habe die EndpointAddress jetzt im Code nach der MSDN-Anleitung Gewusst wie: Hosten eines WCF-Diensts in einem verwalteten Windows-Dienst gesetzt.

Allerdings bekam ich dann den Fehler, dass ein Contract fehlen würde.

Ich habe einen reingeschrieben, der genauso aussah wie mein ServiceContract in meinem WCFService, allerdings kam dann die Fehlermeldung, dass der Vertragsname WindowsServiceKlasse.IService1 nicht in der Liste der Verträge in WCFService.WCFServiceklasse vorhanden sei.

...wie definiere ich den Contract so, dass sich der Windows Dienst mit dem WCF-Dienst verträgt?

edit, alles klar, hab einfach folgende Zeile geändert:

host.AddServiceEndpoint(typeof(MeinWCFProjekt.IService1), new BasicHttpBinding(), address);

Jetzt will er noch ein Behavior, wie prophezeit 😉

edit2: wie kann ich das Behavior denn anpassen, wenn der Windows Service und der WCF - Service in getrennten Projekten liegen?

edit3:Gefunden (endlich): How to: Publish Metadata for a Service Using Code

Ich habe jetzt ein Windows-Service-Projekt, in dem ich die DLL des WCF-Projekts referenziere. So kann ich einfach die DLL austauschen, wenn ich was am WCF-Projekt geändert habe.
Kann ich trotzdem eine Projektübergreifende app.config haben?

G
538 Beiträge seit 2008
vor 12 Jahren

Kurzer Hinweis zur AppConfig:
Es wird die config geladen, die der Einstiegsapplikation entspricht.
Konfigurationen von DLLs werden nicht geladen.

Bei dir würde also wenn du BI.dll und Service.exe hast nicht die BI.dll.config geladen sondern Service.exe.config.

In letzterer kannst du alles konfigurieren, was du brauchst.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

I
Infowissler Themenstarter:in
27 Beiträge seit 2011
vor 12 Jahren

Ok danke, ich versuch dann mal, von meinem WCF-Projekt aus auf die Windows Service Konfig zuzugreifen.

Jetzt würde ich das ganze noch mit etwas anderem als dem WCF TestClient testen, z.B. mit soapui. Allerdings bekomme ich da immer den Fehler "Not Found", egal, welchen EndPoint ich angebe.

edit: zu den Endpoints: Alles klar, hatte WSHTTPBinding statt BasicHTTPBinding angegeben.

Aber irgendwie klappt es nicht, dass ich in meinem WCF-Projekt auf mein Windows Service-Projekt und auf dessen Properties zugreife 😦

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo Infowissler,

Aber irgendwie klappt es nicht, dass ich in meinem WCF-Projekt auf mein Windows Service-Projekt und auf dessen Properties zugreife

Warum nicht bzw. wie äußert sich das. Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 5.

Die Anwendungskonfigurationsdatei (app.config) ist wie der Name schon sagt nur für die Anwendung da*. D.h. alles was vorher in *.dll.config war kann einfach rüberkopiert werden und dann in der Dll ganz normal darauf zugegriffen werden.

* es gibt aber trotzdem Wege wie es anders geht, aber diese verkomplizieren da alles.

Noch ein kleiner Tipp für das Hosten im Windows-Service:
Die Aufteilung in Dll für den WCF-Service der dann vom Windows-Service referenziert wird ist schon super. Damit hast du auch die Möglichkeit den gleichen WCF-Service von einem Konsolen-Host zu referenzieren und das Debuggen des WCF-Service ist ungleich einfacher. Vorausgesetzt dass im Windows-Service fast keine Logik steckt, außer dem Starten des WCF-Dienstes.

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!"

I
Infowissler Themenstarter:in
27 Beiträge seit 2011
vor 12 Jahren

Die Anwendungskonfigurationsdatei (app.config) ist wie der Name schon sagt nur für die Anwendung da*. D.h. alles was vorher in *.dll.config war kann einfach rüberkopiert werden und dann in der Dll ganz normal darauf zugegriffen werden.

* es gibt aber trotzdem Wege wie es anders geht, aber diese verkomplizieren da alles.

Vielen Dank für deine Antworten, haben mir bisher immer weitergeholfen! 😃

Ich habe es jetzt per XMLReader gelöst, ich weiß, gruselig^^ Funktioniert also alles nur, wenn es am Standardspeicherort installiert wird.

Wie geht denn das "ganz normal darauf zugreifen"? Wenn ich in meiner WCF-Klasse WindowsService1.Properties.Settings benutzen will, dann kann ich nur auf den Namespace Settings zugreifen, nicht auf die eigentlichen Werte; wenn ich

WindowsService1.Properties.Settings.

schreibe und dann Intellisense benutzen will, wird einfach nix mehr vorgeschlagen (obwohl ich das WindowsService-Projekt als Verweis dem WCF-Projekt hinzugefügt habe).

Ich hatte für mein WCF-Projekt noch keine app.config erstellt, liegt es evtl. daran? Aber eigentlich dachte ich, dass ich ja auch nicht auf die WCF-Projekt-app.config, sondern auf die WindowsService-Projekt-app.config zugreifen will und deswegen keine WCF-Projekt-app.config brauche.

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo Infowissler,

ich beschreib mal grob die Vorgehensweise für die Konfiguration:1.DLL-Projekt erstellen und dort in den Projekt-Eigenschaften bei Settings diese hinzufügen -> es wird die app.config erstellt die beim Kompilieren zu *.dll.config wird. Weiters erstellt der Designer den Code für den typsisierten Zugriff auf die Settings mittels Properties.Settings.Default.XXX. Diese Klasse ist internal und das ist auch gut so.

1.EXE-Projekt erstellen und dort über Project -> Add new Item (Ctrl + Shift + A) die Anwendungskonfigurationsdatei hinzufügen -> app.config wird erstellt und beim Kompilieren wird diese zur *.exe. config

1.alles was in der app.config des DLL-Projekt in die app.config des EXE-Projekts kopieren - auch oben auf die <configSection> achten und diese entsprechend reinkopieren.

1.somit sind nun alle Konfigurations-Eisntellungen in der Anwendungskonfigurationsdatei, nämlich jener die zur EXE gehört und die beim Start der Anwendung/Dienst geladen wird.

1.der Zugriff mittels Properties.Settings.Default.XXX auf die Einstellungen kann im DLL-Projekt genauso erfolgen und die .net-Runtime (bzw. exakter das Konfigrurationssystem) weiß dann dass es in der *.exe.config nachschauen soll und wenn dort der passende Abschnitt vorhanden ist, sprich der <configSection ... />, dann können auch die Einstellungen geladen werden.

Also von der WCF-Klasse greift du "ganz normal" auf ihre zu dem selben Projekt gehörenden Eigenschaften zu. Dass diese zur Laufzeit in der *.exe.config liegen ist der Klasse wurscht.

Verständlicher?

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!"

I
Infowissler Themenstarter:in
27 Beiträge seit 2011
vor 12 Jahren

Alles klar, super, vielen Dank! 😃