Einführung in Windows-Dienstanwendungen

Einführung in Windows-Dienstanwendu...

Alle reduzieren

Inhalt anzeigen: Englisch mit deutscher Übersetzung

Visual Studio 2010

Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Platform SDK documentation in the MSDN Library.

Note
The Windows Service template and associated functionality is not available in the Standard Edition of Visual Studio.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service's executable file, or by using Visual Studio's deployment features. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs.Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service's process. For more information, see How to: Debug Windows Service Applications.
Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.
The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See "Service Lifetime" below for more information.
Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.
The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Platform SDK documentation.
The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.
Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application's OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Deploying and Installing Services

Visual Studio ships installation components that can install resources associated with your service applications. Installation components register an individual service on the system to which it is being installed and let the Services Control Manager know that the service exists.

After you add installers to your application, the next step is to create a setup project that will install the compiled project files and run the installers needed to install your service. To create a complete setup project, you must add the service project's output to the setup project and then add a custom action to have your service installed. For more information on setup projects, see Setup and Deployment Projects. For more information on custom actions, see Walkthrough: Creating a Custom Action.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.
Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.

Visual Studio 2010

Einführung in Windows-Dienstanwendungen

Mit Microsoft Windows-Diensten, früher als NT-Dienste bekannt, wird das Erstellen von ausführbaren Anwendungen mit langer Laufzeit ermöglicht, die in eigenen Windows-Sitzungen ausgeführt werden. Die Dienste können automatisch gestartet werden, sobald der Computer gestartet wird. Sie können angehalten und neu gestartet werden. Es wird jedoch keine Benutzeroberfläche angezeigt. Dienste eignen sich mit diesen Features ideal zur Verwendung auf einem Server. Sie sind darüber hinaus für alle Fälle geeignet, in denen Funktionen mit langer Laufzeit benötigt werden und Benutzer, die am gleichen Computer arbeiten, nicht gestört werden sollen. Dienste können auch im Sicherheitskontext eines bestimmten Benutzerkontos ausgeführt werden, bei dem es sich nicht um einen angemeldeten Benutzer oder das Standardcomputerkonto handelt. Weitere Informationen zu Diensten und Windows-Sitzungen finden Sie in der Platform SDK-Dokumentation in der MSDN Library.

Hinweis
Die Vorlage Windows-Dienst und die entsprechenden Funktionen stehen in der Standard Edition von Visual Studio nicht zur Verfügung.

Dienste können problemlos erstellt werden, indem eine Anwendung erstellt und als Dienst installiert wird. Nehmen wir z. B. an, dass Leistungsindikatordaten überwacht werden sollen. Sobald die Werte bestimmte Schwellenwerte erreichen, soll reagiert werden. So könnte eine Windows-Dienstanwendung zum Überwachen der Leistungsindikatordaten geschrieben werden, die Anwendung bereitgestellt und anschließend mit dem Sammeln und Analysieren von Daten begonnen werden.

Der Dienst wird als Microsoft Visual Studio-Projekt erstellt. In ihm wird Code definiert, von dem gesteuert wird, welche Befehle an den Dienst gesendet werden können. Darüber hinaus wird festgelegt, welche Aktionen durchgeführt werden sollen, sobald diese Befehle empfangen werden. Zu den Befehlen, die an einen Dienst gesendet werden können, zählen das Starten, Anhalten, Fortsetzen und Beenden des Diensts. Zudem können Sie benutzerdefinierte Befehle ausführen.

Nachdem die Anwendung erstellt wurde, kann sie installiert werden. Dazu wird das Befehlszeilen-Dienstprogramm InstallUtil.exe ausgeführt und der Pfad zur ausführbaren Datei des Diensts übergeben. Die Bereitstellungsfeatures von Visual Studio können ebenfalls verwendet werden. Dann kann der Dienst mit dem Dienststeuerungs-Manager gestartet, beendet, angehalten, fortgesetzt und konfiguriert werden. Viele dieser Aufgaben können auch im Server-Explorer im Knoten Dienste oder durch Verwenden der ServiceController-Klasse ausgeführt werden.

Dienstanwendungen undandere Visual Studio-Anwendungen

Die Funktionsweise von Dienstanwendungen unterscheidet sich von vielen anderen Projekttypen in mehrfacher Hinsicht:

Die kompilierte ausführbare Datei, die von einem Dienstanwendungsprojekt erstellt wird, muss auf dem Server installiert werden. Erst dann kann das Projekt sinnvoll funktionieren. Das Debuggen oder Ausführen einer Dienstanwendung kann nicht durch Drücken von F5 oder F11 gestartet werden. Ein Dienst kann nicht direkt ausgeführt werden, und es besteht keine Möglichkeit, in den Code zu springen. Stattdessen muss der Dienst installiert und gestartet werden. Ein Debugger muss an den Prozess des Diensts angehängt werden. Weitere Informationen finden Sie unter Gewusst wie: Debuggen von Windows-Dienstanwendungen.
Im Gegensatz zu einigen Projekttypen müssen für Dienstanwendungen Installationskomponenten erstellt werden. Mit den Installationskomponenten wird der Dienst auf dem Server installiert und registriert. Zudem wird mit dem Dienststeuerungs-Manager von Windows ein Eintrag für den Dienst erstellt. Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen von Installern zur Dienstanwendung.
Von der Main-Methode der Dienstanwendung muss der Befehl zum Ausführen der Dienste erteilt werden, die im Projekt enthalten sind. Von der Run-Methode werden die Dienste in den Dienststeuerungs-Manager auf dem entsprechenden Server geladen. Wenn die Projektvorlage für Windows-Dienste verwendet wird, wird diese Methode automatisch geschrieben. Beachten Sie, dass das Laden eines Diensts und das Starten eines Diensts unterschiedliche Vorgänge darstellen. Weitere Informationen finden Sie weiter unten unter "Lebensdauer von Diensten".
Windows-Dienstanwendungen werden in einer anderen Windowstation ausgeführt als der interaktiven Station des angemeldeten Benutzers. Eine Windowstation ist ein sicheres Objekt, das eine Zwischenablage, einen Satz globaler Atome und eine Gruppe von Desktopobjekten enthält. Da die Station des Windows-Diensts keine interaktive Station ist, sind aus einem Windows-Dienst ausgelöste Dialogfelder nicht sichtbar, sodass das Programm möglicherweise nicht mehr reagiert. Entsprechend ist es notwendig, Fehlermeldungen im Windows-Ereignisprotokoll zu protokollieren, anstatt sie in der Benutzeroberfläche auszulösen.
Die von .NET Framework unterstützten Windows-Dienstklassen unterstützen keine Interaktion mit interaktiven Stationen, das heißt angemeldeten Benutzern. .NET Framework enthält auch keine Klassen, die Stationen und Desktops enthalten. Wenn der Windows-Dienst mit anderen Stationen interagieren muss, müssen Sie auf die nicht verwaltete Windows-API zugreifen. Weitere Informationen finden Sie in der Platform SDK-Dokumentation.
Die Interaktion des Windows-Diensts mit dem Benutzer oder anderen Stationen muss sorgfältig entwickelt werden, um Szenarios zu berücksichtigen, wie das Nichtvorhandensein von angemeldeten Benutzern oder Situationen, in denen der Benutzer über eine unerwartete Gruppe von Desktopobjekten verfügt. In einigen Fällen kann es zweckmäßiger sein, eine Windows-Anwendung zu schreiben, die durch die Steuerung des Benutzers ausgeführt wird.
Windows-Dienstanwendungen werden in einem eigenen Sicherheitskontext ausgeführt. Sie werden gestartet, bevor sich der Benutzer an dem Windows-Computer anmeldet, auf dem sie installiert sind. Es sollte genau geplant werden, in welchem Benutzerkonto ein Dienst ausgeführt wird. Ein Dienst, der unter dem Systemkonto ausgeführt wird, verfügt über mehr Berechtigungen als ein Benutzerkonto.

Lebensdauer von Diensten

Während seiner Lebensdauer durchläuft ein Dienst mehrere interne Statuswerte. Zuerst wird der Dienst auf dem System installiert, auf dem er ausgeführt werden soll. Bei diesem Vorgang werden die Installationsprogramme für das Dienstprojekt ausgeführt. Der Dienst wird auf dem Computer in den Dienststeuerungs-Manager geladen. Der Dienststeuerungs-Manager stellt das zentrale Dienstprogramm dar, das von Windows für die Verwaltung von Diensten bereitgestellt wird.

Nachdem der Dienst geladen worden ist, muss er gestartet werden, damit die Funktion des Diensts bereitgestellt wird. Sie können einen Dienst aus dem Dienststeuerungs-Manager, aus dem Server-Explorer oder aus dem Code starten, indem Sie die Start-Methode aufrufen. Die Start-Methode übergibt die Verarbeitung an die OnStart-Methode der Anwendung und verarbeitet den dort definierten Code.

Ein Dienst, der ausgeführt wird, kann sich beliebig lange in diesem Status befinden, bis er beendet oder angehalten oder der Computer heruntergefahren wird. Ein Dienst kann einen von drei grundlegenden Zustandswerten aufweisen: Running, Paused oder Stopped. Der Dienst kann zudem den Zustand eines ausstehenden Befehls melden: ContinuePending, PausePending, StartPending oder StopPending. Von diesen Statuswerten wird angezeigt, dass ein Befehl zwar erteilt, aber noch nicht ausgeführt worden ist. Beispielsweise soll ein Dienst angehalten werden, der ausgeführt wird. Sie können den Status abfragen, um zu bestimmen, in welchem Zustand sich ein Dienst befindet, oder WaitForStatus verwenden, um eine Aktion auszuführen, wenn einer dieser Zustände eintritt.

Ein Dienst kann angehalten, beendet oder fortgesetzt werden, indem der Dienststeuerungs-Manager oder der Server-Explorer verwendet wird. Außerdem können Methoden programmgesteuert aufgerufen werden. Von jeder dieser Aktionen kann im Dienst eine zugeordnete Prozedur aufgerufen werden (OnStop, OnPause, oder OnContinue), in der Sie eine zusätzliche Verarbeitung definieren können, die ausgeführt werden soll, sobald sich der Zustand eines Diensts ändert.

Diensttypen

In Visual Studio mit .NET Framework können zwei Diensttypen erstellt werden. Diensten, die den einzigen Dienst in einem Prozess darstellen, wird der Typ Win32OwnProcess zugewiesen. Diensten, die einen Prozess mit einem anderen Dienst gemeinsam verwenden, wird der Typ Win32ShareProcess zugewiesen. Zum Abrufen des Diensttyps fragen Sie die ServiceType-Eigenschaft ab.

Möglicherweise werden andere Diensttypen angezeigt, wenn Sie vorhandene Dienste abfragen, die nicht in Visual Studio erstellt wurden. Weitere Informationen dazu finden Sie unter ServiceType.

Dienste und die ServiceController-Komponente

Die ServiceController-Komponente wird verwendet, um die Verbindung zu einem Dienst herzustellen und seinen Zustand zu ändern. Mit einer ServiceController-Komponente besteht die Möglichkeit, einen Dienst zu starten, zu beenden, anzuhalten und fortzusetzen. Außerdem können benutzerdefinierte Befehle an einen Dienst gesendet werden. Die ServiceController-Komponente muss jedoch nicht notwendigerweise verwendet werden, sobald eine Dienstanwendung erstellt wird. Tatsächlich sollte die ServiceController-Komponente in den meisten Fällen in einer separaten Anwendung vorhanden sein, nicht in der Windows-Dienstanwendung, in der der Dienst definiert wird.

Weitere Informationen finden Sie unter ServiceController.

Bereitstellen und Installieren von Diensten

Im Lieferumfang von Visual Studio sind Installationskomponenten enthalten, mit denen Ressourcen installiert werden können, die Dienstanwendungen zugeordnet sind. Von Installationskomponenten wird ein einzelner Dienst auf dem System registriert, auf dem er installiert wird. Dem Dienststeuerungs-Manager wird mitgeteilt, dass der Dienst vorhanden ist.

Wenn Sie der Anwendung Installationsprogramme hinzugefügt haben, erstellen Sie im nächsten Schritt ein Setup-Projekt, mit dem die kompilierten Projektdateien installiert und die zum Installieren des Diensts benötigten Installationsprogramme ausgeführt werden. Zum Erstellen eines vollständigen Setup-Projekts müssen Sie die Ausgabe des Dienstprojekts zum Setup-Projekt hinzufügen und dann eine benutzerdefinierte Aktion einfügen, um den Dienst zu installieren. Weitere Informationen über Setup-Projekte finden Sie unter Setup- und Bereitstellungsprojekte. Weitere Informationen zu benutzerdefinierten Aktionen finden Sie unter Exemplarische Vorgehensweise: Erstellen einer benutzerdefinierten Aktion.

Voraussetzungen

Dienste müssen in einem Projekt für Windows-Dienst-Anwendungen oder einem anderen .NET Framework-fähigen Projekt erstellt werden. Dieses muss beim Erstellen eine EXE-Datei erstellen und von der ServiceBase-Klasse erben.
Projekte mit Windows-Diensten müssen Installationskomponenten für das Projekt und seine Dienste aufweisen. Dies kann problemlos im Eigenschaftenfenster ausgeführt werden. Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen von Installern zur Dienstanwendung.