Используя новый мастер проектов для C# Windows Services, можно теперь начать создавать службу Windows. Будьте внимательны, чтобы не выбрать проект Web Service.

Службы Web рассматриваются в главе 17.

После нажатия OK для создания приложения Windows Service появится окно проектировщика, как в приложениях Windows Forms, но здесь нельзя вставлять компоненты Windows Forms. Окно проектировщика будет использоваться для добавления других компонентов, таких как счетчики производительности и регистрации событий: Выбор свойств этой службы открывает окно редактора свойств:

Сконфигурируем свойства службы:

□ AutoLog означает, что события автоматически регистрируются для запуска и остановки службы.

□ CanPauseAndContinue, CanShutdown и CanStop означают, что служба может обрабатывать специальные запросы pause, continue, shutdown и stop.

□ ServiceName является именем службы, которое записывается в реестр и используется для управления службой.

□ CanHandlePowerEvent является допустимым параметром для служб, работающих на системе Windows 2000. Мы поговорим о параметрах power позже.

По умолчанию используется имя службы WinService1 независимо от названия проекта. Можно установить только одну службу WinService1. Если возникает ошибка установки во время процесса тестирования, то причина может быть в этом. Проверьте, что имя службы изменено на более подходящее в начале разработки службы.

Изменение этих свойств с помощью редактора свойств задает значения нашего класса, производного из

, в методе . Мы уже знаем этот метод из приложений Windows Forms. Со службами он используется аналогичным образом.

Мастер создаст код, но мы изменим имя файла на

, имя пространства имен на , а имя класса на . Мы подробно рассмотрим этот код позже, а пока остановимся на классе .

Класс

является базовым для всех служб .NET. Наш класс выводится из . Этот класс общается со служебным управляющим менеджером при помощи недокументированного вспомогательного класса , который служит просто классом-оболочкой для вызовов API Win32. Этот класс закрытый, поэтому мы не можем его использовать.

Следующая диаграмма последовательностей показывает взаимодействие SCM — класса

и классов из пространства имен . На диаграмме последовательностей просматриваются вертикальные линии жизни объектов и коммуникация, проходящая в горизонтальном направлении. Коммуникация упорядочена по времени сверху вниз:

SCM запускает процесс службы. Вначале вызывается метод

. В методе нашей службы вызывается метод базового класса . регистрирует метод с помощью в SCM и записывает вход в журнал событий.

Следующий шаг — SCM вызывает зарегистрированный метод

в нашей программе службы. сам регистрирует обработчик с помощью и задает статус службы в SCM. Затем вызывается метод , в котором мы должны реализовать код запуска. Если выполнился успешно, то значение ресурса для записывается в журнал событий.

Обработчик реализуется в методе

. SCM вызывает этот метод, когда служба запрашивает изменения. Метод направляет запросы далее в , , , и .

Рассмотрим сгенерированную основную функцию служебного процесса. В ней объявляются массив

классов . Один экземпляр класса создается и передается как первый элемент массива . Если должно выполняться более одной службы внутри этого служебного процесса, то необходимо добавить в массив больше экземпляров специальных служебных классов. Этот массив передается затем в статический метод класса . С помощью метода из мы задаем ссылки SCM для точек входа служб. Основной поток выполнения служебного процесса теперь заблокирован и ожидает завершения службы.

Вот автоматически сгенерированный код: