Benutzer mit den meisten Antworten
[VS2005] Frage zu Windows Diensten

Frage
-
Hi Leute.
Ich habe ehrlich gesagt, noch keinen Plan davon, wie genau Windows-Dienste entwickelt werden. Nachdem ich mich gestern einen Tag durch MSDN, Foren, Blogs und was weiß ich nicht alles gewühlt habe, habe ich auch noch einige Bücher konsultiert. Das Thema ist in sämtlichen meiner Bücher zu VB (meist etwas ältere 2005er Bücher) nicht drin. Die Forenbeiträge, die mir gängige Suchmaschinen dazu auswarfen, waren teilweise sehr unbefriedigend. Dazu bin ich nach einigen Suchen endlich auf einen Hinweis gestoßen, der meine Vermutung stützte, dass ein Template dazu in meiner Standard Version von VB gar nicht enthalten ist. Und irgendwie gehen fast alle Beispiele davon aus, dass man mind. die Professional Version besitzt, und zitieren weder diesen Quellcode noch erklären sie ihn.
Nun die Frage, ob es einer von euch vermag, mir einen zumindest den absoluten Rohcode mal zu posten, den ich brauche, um eine Anwendung zu einem Dienst zu machen. Also den Teil, den VB einem hier abnimmt (wenn man die Professional besitzt). Gegebenenfalls auch ein einfaches Beispiel zum Download, mit dem ich mal rumbasteln kann. Die Beispiele, die ich gefunden habe, waren fast immer mit einem Haufen Zwischentext und über mehrere HTML-Seiten verteilt ... und ganz oft nur pauschale Erklärungen, aber dann ohne konkreten Code. Das brachte mir bei allen bisherigen Versuchen wenig Erfolg.
Ich bin mir auch irgendwie aus allen Erklärungen unschlüssig, ob ich dazu weiterhin eine Main-Form habe oder mein Programm "Form-los" startet, also direkt mit dem Aufruf dieses System.ServiceProcess.ServiceBase, weil der angeblich auch eine "Sub Main" haben soll. Oder??
Ich habe dann zunächst probiert, einen Timer einzubauen, und ihn über OnStart zu aktivieren. Aber irgendwie wird diese Sub beim Debuggen nie aufgerufen. Andererseits ... wie debugge ich eigentlich ein Programm, das eigentlich als Dienst laufen soll? Als Programm? Oder muss ich das jedesmal erstellen, dann als Dienst installieren, testen, wieder löschen/deinstallieren, dann Fehler beseitigen, wieder erstellen, installieren, usw.??
Vielleicht hat ja einer von euch Erfahrung mit sowas, und kann mir da ein wenig Licht ins Dunkel bringen.
Antworten
-
Ich arbeite auf Anweisung hin grundsätzlich auf dem Server, nicht lokal.
Dennis,
dies ist mit dem Visual Studio offiziell keine gute Idee!
Eine Entwicklungsumgebung gehört vollständig lokal installiert ebenso wie die Projekte.
Falls du die Projekte (Quellcode) auf Server 'sichern' willst, dann nutze Source-Verwaltungssysteme wie den Microsoft Team Foundation Server TFS oder ggf Open Source Alternativen wie uva Subversion/svn+Tortoise.
- Als Antwort markiert Dennis Becker Montag, 6. Dezember 2010 07:56
Alle Antworten
-
ob ich dazu weiterhin eine Main-Form habe oder mein Programm "Form-los" startet
Hallo Dennis
ein Dienst hat prinzipiell keine Form(ulare), schon die Forms-Assembly sollte man gar nicht referenzieren. (techn. zwar nicht ganz ausgeschlossen, aber wäre mind. sehr fragwürdig)
Ich empfehle dir zuerst, von einem simplen Console-Projekttyp auszugehen, und sich dort auch intensiv mit Multi-Threading zu befassen
(Starten eines Threads; Kommunikation unter Threads; Threads synchronisieren; Thread-safe Zugriffe auf gemeinsame Ressourcen; asynchrone Vorgänge und Thread-Pool; Threads koordiniert beenden).
Erst wenn du dann deine effektiven Nutz-Klassen 'stabil' in dieser Umgebung eingebettet hast, befasse dich mit Diensten.
Beachte dabei insbesondere, dass hier die klassische Windows-Seite (Win32/SDK/C++!) viel mitzureden hat (unverzichtbares Grundwisssen!), es ist höchstens zur Hälfte eine .NET-Angelegenheit.
Im Speziellen studiere intensiv, wie der Windows Service-Manager mit deinem Dienst interagiert.
Auch über diverse Sicherheitsaspekte solltest du Bescheid wissen, lange bevor du gar den Dienst an Kunden herausgibst!
Zum debuggen ist es oft von Vorteil, deinen allgemeinen Source-Code sowohl im genannten Console-Projekt sowie im Service-Projekt einzubinden (zB via 'Link' der Quelldateien), denn im Console-Projekt kann man typische Logik-Fehler noch einfacher finden. Erst dann, um Probleme spezifisch für den Dienst-Kontext zu debuggen, kann man zB an den Dienst zu Laufzeit 'attachen':
http://msdn.microsoft.com/de-de/library/7a50syb3(VS.80).aspx
-
Erstmal Danke für die vielen Hinweise für weitere Recherchen. Werde mich mal damit in den nächsten Tagen beschäftigen. Klingt nach viel Stuff. :-/
Was die Forms angeht, noch eine Ergänzungsfrage: Wie sieht das aus, wenn man einen Dienst haben möchte, der aber zudem (etwa über den SysTray) eine Editier- oder Zugriffs-Möglichkeit anbieten soll, also z.b. ein TimerEvent zu steuern, die Zeit oder Häufigkeit zu ändern, in der es im Dienst "passiert". Von Virenschonern z.B. kennt man das ja. Müssen dann dieser "Timer-Dienst" und das Konfig-Programm zwei verschiedene Prozesse bzw. Programme sein? Oder kann das auch ein Programm leisten, also der Dienst z.B. zusätzlich im Systray ein Icon erzeugen, das dann mit dem Windows-User interagieren kann, u.A. Forms oder Eingabedialoge öffnet und dgl.?
Nach erneutem Suchen bin ich endlich auf einen Beispielcode, der zumindest das Grundgerüst enthält. Vielleicht hätte ich mich gestern nicht so lange mit einzelnen nicht funktionierenden Beispielen aufhalten sollen. :-)
Jedenfalls habe ich jetzt eines das gut aussieht. Dank Thomas' Hinweisen klappt es auch den Dienst zu installieren (auch wenn das erst ein paar Probleme bereitete, da auch hier offenbar der Zugriff auf Serverdaten von Windows verweigert wird, ähnlich wie beim HTML-Aufruf in CHM-Files, die klappen auch nur lokal). Blödes Windows 7. ;-)
Aber dann ...
- zum einen startet der Dienst nicht automatisch, obwohl ich auf automatic gestellt habe.
- zum anderen lässt er sich auch nicht manuell starten (vermutlich der Grund für ersteres). Die Fehlermeldung ist fast nostalgisch-simpel gehalten "Zugriff verweigert." ... nix von worauf, von wem, wodurch.
Wo such ich da jetzt am besten nach Ursachen?
Grad etwas ratlos, ...
Dennis.
-
...wenn man einen Dienst haben möchte, der aber zudem (etwa über den SysTray) eine Editier- oder Zugriffs-Möglichkeit anbieten soll, also z.b. ein TimerEvent zu steuern, die Zeit oder Häufigkeit zu ändern, in der es im Dienst "passiert".
Dennis,
...kann das auch ein Programm leisten, also der Dienst z.B. zusätzlich im Systray ein Icon erzeugen, das dann mit dem Windows-User interagieren kann, u.A. Forms oder Eingabedialoge öffnet und dgl.?
spätestens seit Vista ist es praktisch 'untersagt', dass Dienste mit dem GUI des angemeldeten Users interagieren.
Es braucht also neben dem eigentlichen Windows-Service (Prozess, 'unsichtbar') noch irgend eine weitere App oder 'Komponente', die mit dem 'normalen' UI Kontext (=Shell) des angemeldeten Users startet/läuft (und sich zB im SysTray sichtbar macht). Dann braucht es eine Art von Kommunikation zwischen dem Windows-Service und dem UI-Teil, also nur zB WCF, Remoting oder Sockets, NamedPipes uva (IPC).
-
...offenbar der Zugriff auf Serverdaten von Windows verweigert wird, ähnlich wie beim HTML-Aufruf in CHM-Files, die klappen auch nur lokal). Blödes Windows 7. ;-)
...Fehlermeldung ist fast nostalgisch-simpel gehalten "Zugriff verweigert." ... nix von worauf, von wem, wodurch.
Dennis,
es hängt da viel vom Benutzerkonto ab, unter welchem du den Dienst installierst/startest!
Etliche System-Kontos erlauben etwa gar keinen Netzwerk-Zugriff.
Ich kann nicht genug unterstreichen, dass alle Sicherheitsaspekte gründlich zu studieren sind, bevor man den eigenen Dienst etwa an Kunden herausgibt. Ansonst reisst man uU riesige Sicherheitslecks in dessen Infrastruktur! (bzw Kunde verweigert Installation deines Dienstes)
Neben dem Benutzerkonto gilt generell, dass in einem Service längst nicht alle Praktiken zulässig sind, welche in einer 'normalen' Forms-App vieleicht noch liefen. Man muss sich stark auf nur elementare Vorgänge einschränken, insbesondere nicht blind fremden Code (Assemblies) mit einbinden.
Was du mit HTML/CHM-Aufruf meinst ist mir nicht klar, wäre aber (im Zusammenhang mt Diensten?) eher fragwürdig. -
Mit CHM meinte ich nur eine äquivalente Situation, wo auch aus "Sicherheitsgründen" der Zugriff auf nicht lokal gespeicherte Daten grundsätzlich verweigert wird vom System. Darum konnte ich vor einiger Zeit HTML-Hilfen zwar compilieren aber nie testen. Ich arbeite auf Anweisung hin grundsätzlich auf dem Server, nicht lokal. Und der Aufruf mit dem (lokalen) Hilfe-Anzeig-Tool von Windows auf die (extern aufm Server hinterlegte) Hilfedatei funktionierte eben nicht. Diese Funktion lässt sich auch nicht irgendwo aktivieren, die ist einfach geblockt und pasta. Naja, anderes Thema. :-)
Zurück zum Dienst:
Auch hier (also beim Dienst) sind - deiner Antwort zu entnehmen - Sicherheitsaspekte der Grund, wieso mein Dienst abstürzt bzw. gar nicht erst "ins Rollen kommt". Ich check das mal ab, in wie weit ich da weiterkomme, wenn ich Administratorrechte habe.
Und ich pack da nicht irgendwelchen Fremdcode blind rein. Natürlich nicht. Im Moment tut der Prozess auch gar nix, außer halt einen Timer initialisieren, und dort eine Msgbox ausgeben, wenn ein gewisser Zeitpunkt / Interval erreicht ist. Ein ganz banaler Test also. Aber dahin komme ich ja noch gar nicht, weil er sich gar nicht starten lässt.
Ich frage mich halt, worauf der Dienst da zugreifen will, was ihm dann verwehrt ist. Kann das die Log-Datei sein? Weil ansonsten greift er noch auch nichts zu. Timer erstellen, Msgbox ausgeben, sollte ja keinen Zugriff erzeugen.
Ich stocher mal noch ein bisschen rum ...
LG, Dennis.
-
Ich frage mich halt, worauf der Dienst da zugreifen will, was ihm dann verwehrt ist. Kann das die Log-Datei sein? Weil ansonsten greift er noch auch nichts zu. Timer erstellen, Msgbox ausgeben, sollte ja keinen Zugriff erzeugen.
Dennis,
oh doch, auch all die MsgBox - Dinger solltest du in Diensten ganz schnell 'vergessen', wie alles was nach einem 'GUI' aussieht (schlussendlich auch kein zB Console.WriteLine).
Ich empfehle, hier [mind im Debug-Build aktiv] gründlich + intensiv mit Trace und ggf sogar Tools wie
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
plus Logging (in Datei) zu arbeiten.
-
Ich arbeite auf Anweisung hin grundsätzlich auf dem Server, nicht lokal.
Dennis,
dies ist mit dem Visual Studio offiziell keine gute Idee!
Eine Entwicklungsumgebung gehört vollständig lokal installiert ebenso wie die Projekte.
Falls du die Projekte (Quellcode) auf Server 'sichern' willst, dann nutze Source-Verwaltungssysteme wie den Microsoft Team Foundation Server TFS oder ggf Open Source Alternativen wie uva Subversion/svn+Tortoise.
- Als Antwort markiert Dennis Becker Montag, 6. Dezember 2010 07:56
-
Hallo Dennis,
vielleicht hilft das ja weiter:
http://www.informatik-kosmos.de/ik2s/Windows-Dienst
Zumindest habe ich mir damit eine Dienstanwendung erstellt.
Ein bisschen Anpassung muss noch sein, aber dann läufts super.
Gruß
Bernhard