Практическое руководство. Создание служб Windows How to: Create Windows Services

При создании службы можно использовать шаблон проекта Visual Studio, который называется Служба Windows. When you create a service, you can use a Visual Studio project template called Windows Service. Этот шаблон автоматически выполняет основную часть работы, ссылаясь на необходимые классы и пространства имен, устанавливая наследование от базового класса для служб и переопределяя некоторые методы, которые вы обычно хотите переопределять. This template automatically does much of the work for you by referencing the appropriate classes and namespaces, setting up the inheritance from the base class for services, and overriding several of the methods you’re likely to want to override.

Шаблон проекта «Службы Windows» в экспресс-выпуске Visual Studio отсутствует. The Windows Services project template is not available in the Express edition of Visual Studio.

Для создания функциональной службы необходимо выполнить, как минимум, следующее: At a minimum, to create a functional service you must:

Задайте свойство ServiceName. Set the ServiceName property.

Создайте установщики, необходимые для приложения службы. Create the necessary installers for your service application.

Переопределите и задайте код для методов OnStart и OnStop для настройки режимов поведения службы. Override and specify code for the OnStart and OnStop methods to customize the ways in which your service behaves.

Создание приложения службы Windows To create a Windows Service application

Создайте проект Служба Windows. Create a Windows Service project.

Инструкции по созданию службы без использования шаблона см. в разделе Практический пример. Создание служб программным способом. For instructions on writing a service without using the template, see How to: Write Services Programmatically.

В окне Свойства задайте для своей службы свойство ServiceName. In the Properties window, set the ServiceName property for your service.

Значение ServiceName свойства всегда должно соответствовать имени, указанному в классах установщика. The value of the ServiceName property must always match the name recorded in the installer classes. При изменении этого свойства необходимо также обновить свойство ServiceName классов установщика. If you change this property, you must update the ServiceName property of installer classes as well.

Установите любые из следующих свойств для определения режима работы службы. Set any of the following properties to determine how your service will function.

Свойство. Property	Параметр Setting
CanStop	True , чтобы указать, что служба может принимать запросы на останов работы; false для предотвращения останова службы. True to indicate that the service will accept requests to stop running; false to prevent the service from being stopped.
CanShutdown	True , чтобы указать, что служба хочет принимать уведомления о выключении компьютера, на котором она работает, позволяя ему вызывать процедуру OnShutdown. True to indicate that the service wants to receive notification when the computer on which it lives shuts down, enabling it to call the OnShutdown procedure.
CanPauseAndContinue	True , чтобы указать, что служба может принимать запросы на приостановку или возобновление выполнения; false для предотвращения приостановки и возобновления работы службы. True to indicate that the service will accept requests to pause or to resume running; false to prevent the service from being paused and resumed.
CanHandlePowerEvent	True , чтобы указать, что служба может обрабатывать уведомления об изменениях состояния питания компьютера; false , чтобы не сообщать службе об этих изменениях. True to indicate that the service can handle notification of changes to the computer’s power status; false to prevent the service from being notified of these changes.
AutoLog	True для внесения информационных записей в журнал событий приложения, когда служба выполняет некоторое действие; false для отключения этой функции. True to write informational entries to the Application event log when your service performs an action; false to disable this functionality. Дополнительные сведения см. в разделе Практическое руководство. Запись сведений о службах в журнал. For more information, see How to: Log Information About Services. Примечание. По умолчанию свойство AutoLog имеет значение true . Note: By default, AutoLog is set to true .

Когда CanStop или CanPauseAndContinue имеют значение false , диспетчер служб будет отключать пункты меню, отвечающие за остановку, приостановку или возобновление работы службы. When CanStop or CanPauseAndContinue are set to false , the Service Control Manager will disable the corresponding menu options to stop, pause, or continue the service.

Откройте редактор кода и введите данные для выполнения операций для процедур OnStart и OnStop. Access the Code Editor and fill in the processing you want for the OnStart and OnStop procedures.

Переопределите все прочие методы, для которых необходимо определить функциональные возможности. Override any other methods for which you want to define functionality.

Добавить установщики, необходимые для приложения службы. Add the necessary installers for your service application. Дополнительные сведения см. в разделе Практическое руководство. Добавление установщиков в приложение-службу. For more information, see How to: Add Installers to Your Service Application.

Скомпилируйте проект, выбрав в меню Сборка пункт Собрать решение. Build your project by selecting Build Solution from the Build menu.

Не нажимайте клавишу F5 для запуска проекта — таким способом нельзя запустить проект службы. Do not press F5 to run your project — you cannot run a service project in this way.

Установите службу. Install the service. Дополнительные сведения см. в разделе Практическое руководство. Установка и удаление служб. For more information, see How to: Install and Uninstall Services.

Службы Windows

Создание службы для Windows

Одним из важнейших компонентов ОС Windows являются службы. Фактически это отдельные приложения, которые не имеют графического интерфейса и которые выполняют различные задачи в фоновом режиме. Службы могут быть запущены при старте операционной системы, так и в любой другой момент работы пользователя. Распространенным примером служб являются различные веб-серверы, которые в фоновом режиме прослушивают определенный порт на наличие подключений, и если подключения имеются, то взаимодействуют с ними. Это могут быть также различные вспомогательные сервисы обновлений для других установленных программ, которые обращаются к серверу, чтобы узнать, есть ли новая версия приложения. В общем то мы можем открыть панель служб и сами увидеть все установленные и запущенные службы:

Рассмотрим, как создавать свои службы в C#. В качестве реализуемой задачи выберем наблюдение за изменениями в определенной папке в файловой системе. Теперь создадим для ее выполнения службу.

Вначале создадим новый проект, который будет иметь тип Windows Service . Назовем проект FileWatcherService:

После этого Visual Studio генерирует проект, который имеет все необходимое. Хотя в принципе нам необязательно выбирать именно этот тип проекта, можно было бы создать проект библиотеки классов, и затем в нем определить все необходимые классы.

Итак, новый проект выглядит следующим образом:

Здесь также есть файл Program.cs и есть собственно узел службы Service1.cs .

Служба представляет обычное приложение, но она не запускаетс сама по себе. Все вызовы и обращения к ней проходят через менеджер управления службами (Service Control Manager или SCM). Когда служба запускается автоматически при старте системы или вручную, то SCM обращается к методу Main в классе Program:

Метод Main по умолчанию определен таким образом, чтобы запускать сразу несколько служб, которые определены в массиве ServicesToRun. Однако по умолчанию проект содержит только одну службу Service1. Сам запуск производится с помощью метода Run: ServiceBase.Run(ServicesToRun) .

Сама запускаемая служба представлена узлом Service1.cs. Однако на самом деле это не простой файл кода. Если мы откроем этот узел, то увидим в нем файл дизайнера службы Service1.Designer.cs и класс Service1.

Класс Service1 собственно представляет службу. По умолчанию он имеет следующий код:

Класс службы должен наследоваться от базового класса ServiceBase . Этот класс определяет ряд методов, важнейшие из которых метод OnStart() , который запускает действия, выпоняемые службой, и метод OnStop() , останавливающий службу.

После того, как SCM вызовет метод Main и зарегистрирует службу, происходит непосредственный ее вызов через запуск метода OnStart.

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

Кроме этих двух методов в классе службы можно переопределить еще несколько методов базового класса ServiceBase:

OnPause : вызывается при приостановке службы

OnContinue : вызывается при возобновлении работы службы после ее приостановки

OnShutdown : вызывается при завершении работы Windows

OnPowerEvent : вызывается при изменении режима электропитания

OnCustomCommand : вызывается при получении службой пользовательской команды от Менеджера Управления Службами (Service Control Manager / SCM)

В конструкторе класса Service1 вызывается метод InitializeComponent() , который определен в файле дизайнера Service1.Designer.cs:

Единственное, что надо в нем отметить, это установка названия службы (свойство ServiceName):

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

Теперь изменим код службы следующим образом:

Ключевым классом, который инкапсулирует всю функциональность, является класс Logger. С помощью объекта FileSystemWatcher он будет вести мониторинг изменений в папке D://Temp. В методе Start() устанавливается, что мы будем отслеживать изменения через объект FileSystemWatcher. И вся работа будет идти, пока булевая переменная enabled равна true . А метод Stop() позволит завершить работу класса.

События FileSystemWatcher позволяют отслеживать все изменения в наблюдаемой папке. При этом будет вестись запись изменений в файл templog.txt. Чтобы не было гонки ресурсов за файл templog.txt, в который вносятся записи об изменениях, процедура записи блокируется заглушкой lock(obj) .

В итоге после создания, изменения, переименования и удаления файл лога будет содержать что-то наподобие:

В самом классе службы Service1 в конструкторе устанавливается ряд опций:

В методе OnStart() для запуска объекта Logger вызывется новый поток:

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

Когда от менеджера SCM поступает команда на остановку службы, срабатывает метод OnStop, который вызывает метод logger.Stop() . Дополнительная задержка позволит потоку логгера остановиться:

Однако самого класса службы еще недостаточно. Нам необходимо еще создать устанощик службы.

Как в Windows 10 создать собственную системную службу

Открыв Диспетчер задач и переключившись на вкладку «Подробности», можно обнаружить ряд процессов, которые явно не имеют никакого отношения к запущенным пользователем прикладным программам. Многие из таких процессов принадлежат службам — особым программным модулям, стартующим вместе с Windows, работающим в скрытом режиме и выполняющим подчас очень важную работу. Но тут у многих может возникнуть вопрос.

А разве прикладные программы не могут работать в скрытом режиме и точно так же запускаться вместе с Windows, будучи добавленными в автозагрузку?

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

Это хороший вопрос, и на него можно ответить утвердительно, однако понятие «автозагрузка» часто употребляется в широком смысле слова без различия, что именно и как именно загружается. Если вы имеете общие представления о работе процессов Linux, то наверняка знакомы с такой сущностью как демон. Это процесс, но процесс несвязанный с каким-либо конкретным пользователем и работающий как-бы автономно. Службы в Windows очень похожи на этих самых демонов, они тоже независимы от пользователей. Когда вы добавляете в автозагрузку программу, пусть даже не имеющую графического интерфейса, она запускается в рабочем окружении пользователя при входе последнего в свою учетную запись, тогда как службы запускаются еще до ввода пользователем логина и пароля и напрямую с ним не взаимодействуют.

Теперь, когда вы поняли основную разницу между добавленными в автозагрузку приложениями и службами, мы научимся создавать такие службы сами и использовать их для разных целей, например, для мониторинга портов или еще чего-нибудь; главное — это найти программу или скрипт, который будет выполнять необходимое вам действие.

А еще вам понадобиться бесплатный инструмент Non-Sucking Service Manager, который «превратит» обычный процесс в службу. Название программы не очень благозвучное даже для носителя английского языка, но это не так уже и важно. Главное, что она работает. Скачать ее можно с сайта разработчика nssm.cc/download.

Создавать службу (чисто для примера) мы будем из процесса скрипта PowerShell , замеряющего среднее значения загруженности процессора и сохраняющего данные в текстовый лог.

Вот так он выглядит «изнутри».

Сначала проверим, работает ли сам скрипт. Кликаем по нему ПКМ и выбираем «Выполнить с помощью PowerShell».

Если в консоли будет выведен запрос на разрешение выполнения скриптов, вводим Y и нажимаем ввод .

Если скрипт заработал, вы увидите в консоли текст «Транскрибирование запущенно, выходной файл… и его адрес».

В результате в каталоге со скриптом у вас появится каталог «Logs» с файлом отчета в простом текстовом формате.

Создаем службу

Теперь переходим к работе с Non-Sucking Service Manager. Открыв от имени администратора командную строку и перейдя в расположение исполняемого файла утилиты nssm.exe соответствующей разрядности, выполняем команду nssm install logCPUAvg , где logCPUAvg — имя новой службы.

В открывшемся окошке установщика вы увидите три поля:

• Path – в нем указываем путь к обработчику, то есть PowerShell, файл консоли находится в папке C:\Windows\System32\PowerShell .
• Startup directory – папка с исполняемым файлом обработчика, поле заполнится автоматически.
• Arguments – в этом поле прописываем команду -ExecutionPolicy Bypass -NoProfile -File «полный-путь-к-скрипту» .

Аргумент ExecutionPolicy нужен для предоставления скрипту временных прав на запуск. Если в качестве службы вы устанавливаете какую-нибудь утилиту, то поле может быть оставлено как пустым, так и с указанным в нём аргументом данной конкретной утилиты.

Всё готово, жмем «Install service», чтобы установить службу.

Окно установщика содержит и другие вкладки, дополнительные. Например, на вкладке «Details» можно указать описание и отображаемое в оснастке управления службами имя службы, которое будет отличаться от указанного в команде nssm install, а на вкладке «Log on» выбрать учетную запись, от имени которой станет работать служба.

По умолчанию создаваемая служба работает от имени самой системы, как и положено. Открыв оснастку управления службами, вы увидите в списке и свою службу. Она будет иметь тип запуска «Автоматически», но находиться в остановленном состоянии. Запустится она при следующей загрузке, либо вы сами можете ее запустить.

То, что скрипт заработал, станет видно из того, что в месте его расположения появится папка «Logs» , при этом вывод самой консоли будет скрыт. И вот что интересно. Запустив службу, мы вышли из учетной записи в 12.46, а затем вошли в нее в 12.50, но служба продолжала работать даже в наше отсутствие в системе! Это еще раз говорит о том, что системная служба не связана с пользовательским окружением.

Удаление службы

Помимо того, что вы можете остановить службу в оснастке, переведя ее в статус «Отключена», вы властны ее полностью удалить с помощью той же NSSM. Для этого в командной строке выполняем команду nssm remove имя-службы .

И подтверждаем действие нажатием кнопки «Да» в миниатюрном диалоговом окошке.

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