[Windows] Service erstellen?

[Gast]

Hi,

ich möchte unter Windows (C# mit .NET) ein Programm schreiben welches vom User nicht so ohne weiteres geschlossen werden kann. Ich habe bereits den X-Button deaktiviert usw. aber z.b. mit Task Manager->Task beenden kann man das Programm noch immer "kalt" abschießen. Auch wenn sich der User ab- und wieder anmeldet läuft das Programm logischerweise nicht mehr. Ich möchte aber dass wenn es einmal gestartet wird es immer läuft, bis der PC abgeschaltet wird.
Sowas müsste doch mit einem Windows Service realisierbar sein, oder? Kennt sich da jemand aus bzw. kann mich jemand in die richtige Richtung leiten (Internet Ressourcen usw.)

danke

[Sephiroth]

selbst gemacht nicht aber auf die schnelle hab ich das hier gefunden

http://www.mycsharp.de/wbb2/thread.php?threadid=18902
http://www.codeproject.com/KB/system/WindowsService.aspx
http://www.codeproject.com/KB/dotnet/simplewindowsservice.aspx

[Gast]

Egal wie leicht oder schwer es ist den Dienst zu erstellen und zu debuggen (weiß nicht, ob es da brauchbare Tools, ich habe noch keine gefunden), wirst du bei einem Dienst immer auf diverse Probleme stoßen, da der Dienst eben nicht interaktiv läuft:

1.) Benutzerein- und Ausgaben können nicht direkt vorgenommen werden. Du musst dir also z.B. für Fehlermeldungen ein sehr gutes Konzept fürs Logging ausdenken. Wenn du eventuell irgendwelche Subprogramme aufrufst, so ist diese Ausgabe auch nicht am Bildschirm zu sehen.

2.) Gewisse Formularoperationen werfen einen Fehler in .NET wenn der Benutzer nicht im UserInteractive Mode angemeldet ist (also wenn nur die .exe läuft ohne das Userprofil zu laden).

3.) Da der Dienst unabhängig vom Benutzer ist, stehen dir keine Laufwerksbuchstaben zur Verfügung. Diese werden erst beim Anmelden des Benutzers verbunden.

4.) Da das Userprofil nicht geladen wird, können einige Programme, die vom Dienst gestartet werden nicht richtig funktionieren.

5.) Beim Zugriff auf Netzwerkfreigaben ergibt sich die Frage nach der Berechtigung. Wenn der Dienst unter LocalSystem läuft, dann hast du keinen Zugriff auf andere Server. Wenn du den Dienst unter einem Domänenbenutzer startest, dann ist das Passwort fix abgespeichert und darf nicht geändert werden, sonst funktioniert der Dienst beim nächsten Neustart nicht mehr. Das war bei unserem Server sehr schön, da irgendein Depp auf die Idee gekommen ist den SQL Server Dienst als Domänen Admin zu starten. Nach 3 Monaten habe ich natürlich nicht mehr daran gedacht, dass das vielleicht das geänderte Passwort war :P

[Coda]

Selbst einen Service kann man beenden. Und das ist auch gut so.

[Gast]

Egal wie leicht oder schwer es ist den Dienst zu erstellen und zu debuggen (weiß nicht, ob es da brauchbare Tools, ich habe noch keine gefunden), wirst du bei einem Dienst immer auf diverse Probleme stoßen, da der Dienst eben nicht interaktiv läuft:


Einen Dienst zu debuggen ist doch kinderleicht mit VS.NET. Man muss sich ggf. nur eine manuelle Startbedingung einbauen, da ja das Anhängen an einem Prozess (also die Menüauswahl mit der Maus) auch etwas Zeit braucht.


1.) Benutzerein- und Ausgaben können nicht direkt vorgenommen werden. Du musst dir also z.B. für Fehlermeldungen ein sehr gutes Konzept fürs Logging ausdenken. Wenn du eventuell irgendwelche Subprogramme aufrufst, so ist diese Ausgabe auch nicht am Bildschirm zu sehen.


Dass man keine MessageBox aufpoppen lassen kann und sollte, versteht sich doch von selbst. Fehler behandelt man mit try/catch und schreibt die Fehler dann entweder in eine Textdatei oder in eine DB weg.


3.) Da der Dienst unabhängig vom Benutzer ist, stehen dir keine Laufwerksbuchstaben zur Verfügung. Diese werden erst beim Anmelden des Benutzers verbunden.


Das trifft aber nur auf Netzlaufwerkverbindungen zu, ansonsten kannst du natürlich über den Buchstabe auf Laufwerke zugreifen. Und für Netzwerk Shares kann man ja dann eben manuell über Win32 API Zugrife ein Share mit einem Laufwerksbuchstaben verbinden.


Beim Zugriff auf Netzwerkfreigaben ergibt sich die Frage nach der Berechtigung. Wenn der Dienst unter LocalSystem läuft, dann hast du keinen Zugriff auf andere Server.

Wieso sollte das nicht gehen? Unsere Dienste laufen unter Local System und machen nichts anderes. Probleme würde es geben, wenn du auf Ressourcen der Internet Zone zugreifen würdest. Dann müsstest du entweder den Account wechseln oder die Policies ändern, aber im eigenen Netzwerk läuft das ja in der Intranet Zone.

[Gast]

Dass man keine MessageBox aufpoppen lassen kann und sollte, versteht sich doch von selbst.

Klar kann man eine MessageBox aufpoppen lassen. Der Service braucht hierzu ein bestimmtes Privileg. Aber man sollte es nicht, da stimme ich zu.

Ich weiss auch nicht wo das Problem ist, einen Service zu Debuggen. Man kann den Service leicht so bauen, dass man ihn zum Zwecke des Debuggens, wie ein normales Consolen-Programm startet und beendet.

[fezie]

Bei den Diensten unter Win 7 gibt es ein Häckchen für "Datenaustausch zwischen Dienst und Desktop zulassen", was bei dem O&O Defrag Dienst zum Beispiel an ist.
Ich glaub das gabts schon zu Windows 2000 Zeiten, vielleicht aber auch erst seit XP.
Geht natürlich nur wenn lokales Systemkonto ausgewählt ist und kein seperater Account für den Dienst genutzt wird.

[Gohan]

Egal wie leicht oder schwer es ist den Dienst zu erstellen und zu debuggen (weiß nicht, ob es da brauchbare Tools, ich habe noch keine gefunden), wirst du bei einem Dienst immer auf diverse Probleme stoßen, da der Dienst eben nicht interaktiv läuft:

1.) Benutzerein- und Ausgaben können nicht direkt vorgenommen werden. Du musst dir also z.B. für Fehlermeldungen ein sehr gutes Konzept fürs Logging ausdenken. Wenn du eventuell irgendwelche Subprogramme aufrufst, so ist diese Ausgabe auch nicht am Bildschirm zu sehen.

2.) Gewisse Formularoperationen werfen einen Fehler in .NET wenn der Benutzer nicht im UserInteractive Mode angemeldet ist (also wenn nur die .exe läuft ohne das Userprofil zu laden).

3.) Da der Dienst unabhängig vom Benutzer ist, stehen dir keine Laufwerksbuchstaben zur Verfügung. Diese werden erst beim Anmelden des Benutzers verbunden.

4.) Da das Userprofil nicht geladen wird, können einige Programme, die vom Dienst gestartet werden nicht richtig funktionieren.

5.) Beim Zugriff auf Netzwerkfreigaben ergibt sich die Frage nach der Berechtigung. Wenn der Dienst unter LocalSystem läuft, dann hast du keinen Zugriff auf andere Server. Wenn du den Dienst unter einem Domänenbenutzer startest, dann ist das Passwort fix abgespeichert und darf nicht geändert werden, sonst funktioniert der Dienst beim nächsten Neustart nicht mehr. Das war bei unserem Server sehr schön, da irgendein Depp auf die Idee gekommen ist den SQL Server Dienst als Domänen Admin zu starten. Nach 3 Monaten habe ich natürlich nicht mehr daran gedacht, dass das vielleicht das geänderte Passwort war :P

Einen Dienst zu Debuggen ist höchst einfach. Mit dem .NET Framework werden Tools ausgeliefert, um den Dienst aus Visual Studio heraus zu installieren. Dann wird bei jedem Start des Dienstes immer die aktuelle Assembly geladen. Dann nur noch über Debug > Attach Process an den Dienst hängen und los gehts.

Dann brav mit Try-Catch Blöcken arbeiten, einen Logger wie Log4Net benutzen und die Sache ist gegessen.

Aber wie Coda bereits geschrieben hat. Auch ein Service lässt sich über den Task-Manager einfach abschießen.

[Birdman]

Selbst einen Service kann man beenden. Und das ist auch gut so.
Man könnte den Dienst "hidden" eintragen, dann kann der User zumindest schon mal nicht über die Servicekonsole daran herumnibbeln. Und da der default Windows Taskmanager das killen von Services nicht zulässt, ist man auch da fein raus.

Da müsste also schon wer mit einem ThirdParty Taskmanager dahinter oder zuerst den Service in der Registry sichtbar schalten, ehe da was abgestellt wird.

[Rente]

Man könnte den Dienst "hidden" eintragen, dann kann der User zumindest schon mal nicht über die Servicekonsole daran herumnibbeln. Und da der default Windows Taskmanager das killen von Services nicht zulässt, ist man auch da fein raus.

Da müsste also schon wer mit einem ThirdParty Taskmanager dahinter oder zuerst den Service in der Registry sichtbar schalten, ehe da was abgestellt wird.
Vielleicht eine dummer Frage, aber wie will man sowas an Virenscanner mit entsprechender Heuristik vorbei bekommen? Außerdem, wird der "hidden"-Dienst nicht trotzdem in der Diensteverwaltung angezeigt?

[Gast]

Man könnte den Dienst "hidden" eintragen, dann kann der User zumindest schon mal nicht über die Servicekonsole daran herumnibbeln. Und da der default Windows Taskmanager das killen von Services nicht zulässt, ist man auch da fein raus.

Da müsste also schon wer mit einem ThirdParty Taskmanager dahinter oder zuerst den Service in der Registry sichtbar schalten, ehe da was abgestellt wird.

Blödsinn! Man kann Dienste sehr wohl über den Taskmanager killen, sofern es nicht der Local System Account ist. Und zweitens kann man auch über die CMD Dienste killen/stoppen/starten/installieren/Status abfragen usw.

[Monger]

Wenn ich das hier so lese... es geht nicht zufällig um irgendeinen Kopierschutzmechanismus, oder?

Ich kann mir ansonsten schwer vorstellen, wozu man einen Dienst dermaßen zwanghaft am Leben erhalten will. Wenn man normalerweise einen Service braucht, und der läuft nicht bereits, dann startet man ihn halt.

Wenn der Anwender dann trotzdem einen Dienst killt den ein Programm dringend benötigt, ist er halt selbst schuld. Vor mutwilliger Zerstörung ist kein Programm geschützt.