[gelöst] Windows Service soll bei Fehler jemanden benachrichtigen: Auf welche Weise am besten?

Hallo Leute

Mein Windows-Service überwacht einen Ordner und stellt verrückte Sachen mit Dateien an, die darin gespeichert werden. Für den unwahrscheinlichen Fall, dass dabei mal ein Fehler auftreten sollte, soll irgendjemand davon benachrichtigt werden. Ich befürchte nur, dass ein Eintrag in der Ereignisanzeige nicht auffällig genug wäre.

Meine Ideen dazu wären erstmal:

• Benachrichtigung auf den Bildschirm
• Email an jemanden verschicken

Irgendwelche anderen Ideen oder so? Ich würd mich freuen.

Grüße

Wie wär's mit einem "System Tray Icon"

Hallo,

• Benachrichtigung auf den Bildschirm ist für einen Windows-Service eher ungünstig, weil Du dann Interaktion mit dem Benutzer-Desktop brauchst.
  Deshalb müsste auch eine Tray-Anwendung, wie von MrSparkle vorgeschlagen, IMHO am Besten als Client für den Service implementiert werden.
• Email an jemanden verschicken

ist eine gängige Lösung, und auch nicht schwer umzusetzen.

Gruß, MarsStein

Hallo,

das lässt sich über System.Debug.TraceListener relativ leicht umsetzen. Von diesem kann geerbt werden so zB ein EmailTraceListener implementiert der so konfiguriert wird dass bei einem Fehler od. kritschen Fehler die Email versandt wird.
Auch ein TrayIconListener ist so umsetzbar (als Client von IPC).

Wenn du das alles schön in eine Assembly packst ist das auch wiederverwenbar.

mfG Gü

Also vielen Dank schonmal für die Antworten. 👍
Ich werd mir jetzt nen Kopf drum machen und dann später hier reinschreiben, wie ich's gelöst habe.

Gruß

So, ich habe mich jetzt dafür entschieden eine zusätzliche Monitoring-Anwendung zu schreiben. Diese wird einen NamedPipe-Server laufen lassen. Der Windows-Service kann dann so Nachrichten an die Anwendung schicken.
So kann ich gleich das ganze Logging mitnehmen und im Fehlerfall eine dickes rotes etwas auf den Monitor ausgeben. Natürlich nur wenn jemand angemeldet ist.

edit:
Ohje, das mit den Named Pipes ist nicht ohne. Mein Kopp qualmt. 🤔
In Multithreaded NamePipeServer in C# ein Beispiel dazu.

Mehr dazu nach dem WE. 😁

Ist denk ich ein guter Weg so, nur bei NamedPipes musst etwas aufpassen. Ich meine, da hatte ich schonmal Probleme, wenn eine Desktop Anwendung mit einem Service über diesen Weg reden will (da gabs was mit Berechtigungen und Windows 7 / Vista / 2008).

Daher habe ich damals dann auf Tcp/IP Kommunikation auf LocalHost umgestellt, sobald die Kommunikation über NamedPipes Probleme macht..
Muss jetzt nicht so stimmen, aber am besten mal ausprobieren.

EMails oder gar SMSsen (gibts ja auch manchmal bei sowas) würde ich eher vermeiden. Da müsstest dann nämlich noch aufpassen, dass du nicht jemanden die Mailbox zumüllst (z. B. Fehler, der alle paar Sekunden ausgelöst wird).

Gruß
Roland

Die Idee das über IPC zu machen ist grundsätzlich gut nur würde ich dir auch eher zu einer Implementierung raten die auf Named Pipes verzichtet. Alternativ könntest du z.B. Zyan für die Kommunikation über Remoting benutzen.

IMHO auch ein schöner Weg wäre eine Datenbank (SQL Express wenn nichts anderes im Haus ist) zu verwenden in die geloggt wird. Da bleibst du sehr flexibel und kannst die Daten auch leicht in die gängigen Monitoring-Tools am Markt integrieren.

Ich würde dir ne MessageQueue empfehlen - die ist asynchron und dir gehen also auch alte Fehler nicht verloren.
Die sind auch recht einfach zu implementieren mit WCF

Hallo zusammen. Also vielen Dank nochmal für die Antworten.

MessageQueue's sind im Prinzip ein einfacher und guter Weg, allerdings muss unter Umständen der MessageQueueServer unter Windows installiert werden. Das würde die Installation beim Kunden wieder komplizierter machen.

Zyan ist ein sehr mächtiges Tool, dass relativ einfach zu implementieren ist. Hätte ich wahrscheinlich verwendet, wenn ich nicht schon anders vorgegangen wäre.

Von NamedPipes habe ich wieder Abstand genommen und stattdessen den einfacheren Weg über Tcp-Sockets genommen.

Viele Grüße