Запуск консольного приложения как службы

Обновлено: 04.07.2024

Можно ли запустить клиентское приложение в качестве службы? В одной из статей я описывал способы создания службы Windows штатными средствами ОС. Однако не каждое консольное приложение сможет запуститься как служба, а программы с графическим интерфейсом в принципе не умеют работать подобным образом. Но возможность запустить приложение как службу все же есть, и поможет нам в этом программа с оригинальным названием Non-Sucking Service Manager.

NSSM представляет из себя свободное программное обеспечение с открытым кодом и поддерживает все операционные системы Microsoft, начиная с Windows 2000 и заканчивая Windows 8. NSSM не требует установки, достаточно его загрузить и распаковать. В дистрибутив входят версии для 32- и 64-разрядных ОС. Взять программу можно с сайта nssm.cc, на данный момент последняя стабильная версия 2.21.1, которую я и буду использовать.

Для демонстрации возможностей NSSM попробуем запустить Блокнот Windows в качестве службы на Windows 8.1.

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

Для создания службы с именем notepad запускаем командную консоль, переходим в папку с распакованным NSSM (для 64-разрядной Windows) и вводим команду nssm install notepad , которая открывает окно графического инсталлятора NSSM. Чтобы создать службу, достаточно в поле Path указать путь к исполняемому файлу и нажать кнопку «Install service». Дополнительно в поле Options можно указать ключи, необходимые для запуска службы.

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

На вкладке «Shutdown» перечислены методы остановки и таймауты, используемые при штатном завершении работы или аварийной остановке приложения. Когда NSSM получает команду остановки (напр. при завершении работы приложения), то он пытается остановить контролируемое приложение штатным образом. Если же приложение не отвечает, то NSSM может принудительно завершить все процессы и подпроцессы этого приложения.

Всего есть четыре этапа завершения работы приложения, и по умолчанию они будет использоваться в таком порядке:

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

По умолчанию при падении службы NSSM пытается рестартовать ее. На вкладке «Exit actions» можно изменить автоматическое действие при нештатном завершении работы приложения, а также выставить задержку перед автоматическим перезапуском приложения.

На вкладке «Input/Output (I/O)» можно задать перенаправление ввода\вывода приложения в указанный файл.

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

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

nssm install notepad ″C:\Windows\system32\notepad.exe″

Управление службой

После создания службы с помощью NSSM зайдем в оснастку Services и найдем службу notepad. Как видите, с виду она ничем не отличается от остальных служб, мы также можем ее запустить, остановить или изменить режим запуска. Однако обратите внимание, что в качестве исполняемого файла указан nssm.exe.

А если зайти в Task Manager, то мы увидим следующую картину: в качестве основного (родительского) процесса запущен NSSM, служба notepad запущена как его дочерний процесс, и уже в этом дочернем процессе запущено приложение Блокнот.

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

Для удаления службы вводим команду nssm remove notepad и подтверждаем ее удаление. А введя команду nssm remove notepad confirm , можно обойтись и без подтверждения.

Запуск службы в интерактивном режиме

А дело в том, что для ее запуска необходимо разрешить запуск интерактивных служб на компьютере. Поэтому открываем редактор реестра, находим в разделе HKLM\System\CurrentControlSet\Control\Windows параметр типа DWORD с именем NoInteractiveServices и ставим его значение в 0.

После чего открываем консоль PowerShell и стартуем службу обнаружения командой:

Start-Service -Name ui0detect

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

Такое вот интересное решение для запуска приложений в виде служб Windows. Не самое красивое, но вполне соответствующее своему названию 🙂

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

Для примера откроем редактор реестра и попробуем в разделе HKEY_LOCAL_MACHINE\SECURITY создать подраздел. Как видите, у нас ничего не получилось, нет доступа.

Примечание. Насчет названия учетной записи есть некоторые разночтения. Так в зависимости от того, где она используется, ее могут называть SYSTEM, NT AUTHORITY\SYSTEM, LocalSystem или ComputerName\LocalSystem.

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

PsExec

Утилита командной строки PsExec входит в состав пакета PsTools от Sysinternals. Изначально PsExec предназначена для удаленного управления, но ее можно использовать и для запуска процессов с повышенными привилегиями. Кстати, по этой причине некоторые антивирусы опознают PsExec как ″трояна″.

PsExec не требует установки, достаточно просто скопировать ее в локальную папку и запустить из консоли cmd или powershell. Для удобства использования можно поместить исполняемый файл в системный раздел (C:\Windows\system32). Для примера откроем новое окно командной строки вот такой командой:

psexec.exe -i -s cmd.exe

Ключ -s производит запуск от имени системы, а ключ -i открывает окно в интерактивном режиме. Теперь выполним в новом окне команду whoami и убедимся, что оно запущено от имени пользователя nt authority\system. Таким образом с помощью PsExec можно запустить любое приложение с правами системы.

С PsExec все просто и понятно, этот способ используется с незапамятных времен и до сих пор актуален. Но, исключительно ради разнообразия, рассмотрим еще один способ.

PowerRun

PowerRun — графическая утилита, специально предназначенная для запуска программ с повышенными правами (TrustedInstaller/Nt Authority/System). Установка ей не требуется, достаточно скопировать утилиту в локальную папку и запустить. При желании можно выбрать русскоязычный интерфейс, хотя на мой взгляд в нем нет необходимости. Интерфейс у PowerRun простой, интуитивно понятный, все основные действия вынесены в виде кнопок на центральную панель.

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

Для примера создадим запись для запуска командной строки. Окно должно открываться в нормальном режиме, в качестве рабочей директории задан профиль текущего пользователя (%userprofile%), после запуска выполняется команда whoami.

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

Дополнительно можно на базе созданной записи создать bat- или vbs-скрипт. Это позволит максимально упростить и ускорить процедуру запуска программы с системными правами.

Особо продвинутые пользователи могут запускать PowerRun напрямую из командной строки. Синтаксис и примеры команд можно посмотреть в справке, которая открывается командой PowerRun.exe с ключом /?.

Для примера запустим все ту же консоль и выполним в ней команду whoami:

PowerRun.exe /K whoami

И еще один интересный момент, о котором надо знать при работе с PowerRun. По умолчанию PowerRun умеет запускать программы с правами пользователей Nt Authority/System и TrustedInstaller. С первым более менее понятно, а вот о втором стоит рассказать чуть подробнее.

Начиная с Windows Vista в операционные системы Windows внедрена технология WRP (windows resource protection), предназначенная для защиты файлов и ключей реестра. WRP при помощи исполняемого модуля trustedinstaller.exe ограничивает доступ к критически важным системным ресурсам для всех пользователей, включая и администраторов. Правом доступа к этим ресурсам обладает только системный пользователь TrustedInstaller, который является их владельцем.

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

Иногда может потребоваться взять исполняемый файл и зарегистрировать его в качестве службы Windows. Для этого есть несколько способов, я обычно пользуюсь двумя из них.

Sc.exe

При создании службы с помощью SC нет необходимости вручную создавать записи в реестре и затем перезагружать компьютер, чтобы обеспечить обновление базы данных диспетчером служб. Также SC позволяет указать имя удаленного компьютера, что дает возможность управлять службами как на локальном, так и на удаленном компьютере.

Для создания нового сервиса запускаем команду Sc create . Она создает запись службы в реестре и в базе данных диспетчера служб. Sc create имеет следующий синтаксис:

sc create [ServiceName] [binPath= ] <параметр1= > <параметр2= >

Для примера создадим службу MyService, укажем отображаемое имя My New Service, зададим тип службы и поставим ее на авто-запуск:

Sc create MyService binPath=C:\MyService\MyService.exe DisplayName=″My New Service″ type=own start=auto

Затем откроем оснастку «Services» и посмотрим результат.

Изменять параметры уже созданной службы можно командой Sc config . Например, мне не понравилось отображаемое имя службы и я хочу его изменить:

Sc config MyService DisplayName=″My Service″

Ну и полностью удалить службу можно вот так:

Sc delete MyService

PowerShell

PowerShell может почти все 🙂 , в том числе и управлять службами Windows. Создать новую службу можно с помощью командлета New-Service . Создадим такой же сервис, как и в предыдущем примере, только добавим к нему описание (Description):

New-Service -Name MyService -BinaryPathName C:\MyService\MyService.exe`
-DisplayName ″My New Service″ -Description ″Very Important Service . ″

Изменить параметры службы можно командлетом Set-Service :

Set-Service -Name MyService -Description ″Not Very Important Service″ -StartupType Manual

Есть ли способ скрыть окно консоли при выполнении консольного приложения?

В настоящее время я использую приложение Windows Forms для запуска консольного процесса, но я не хочу, чтобы окно консоли отображалось во время выполнения задачи.

попробуйте запустить консольное приложение из запланированной задачи.

Если вы используете ProcessStartInfo класс, вы можете установить стиль окна как скрытый - в случае консольных (не GUI) приложений вы должны установить CreateNoWindow на true :

Мне пришлось задушить его интернет-соединение, чтобы победить его;) Это не сработало для вызова инструмента командной строки. Используется yourprocess.StartInfo.CreateNoWindow = true; вместо этого см. ниже. Не скрывает окно консоли, требуется StartInfo.CreateNoWindow = true.

Если вы написали консольное приложение, вы можете сделать его скрытым по умолчанию.

Создайте новое консольное приложение, затем измените тип «Тип вывода» на «Приложение Windows» (выполняется в свойствах проекта).

Я пытался скрыть свою консоль, не вызывать что-то еще, а затем скрыть ее (как предполагает принятый ответ) - так что это был лучший вариант для меня. Благодарность! Принятый ответ предполагает, что это указано в вопросе. Самый простой способ .. очень понравилось .. мы, конечно, не хотим показывать окно, потому что оно будет запускать из него другой процесс для меня .. Это позволяет обойти проблемы с ProcessStartInfo, где вы указываете учетные данные пользователя, и этот пользователь находится в системе или является текущим пользователем. В этой ситуации свойство CreateNoWindow игнорируется, поэтому вы всегда получаете окно консоли. Установив консольное приложение на приложение Windows, но без окна, вы не получите окна.

Если вы используете класс процесса, вы можете написать

до yourprocess.start(); и процесс будет скрыт

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

Простой ответ: перейдите в свойства консольного приложения (свойства проекта). На вкладке «Приложение» просто измените «Тип вывода» на «Приложение Windows». Вот и все.

Яблочко. Это то же самое, что создать приложение Windows, которое не вызывает никаких форм. Это правильный ответ. Ни один из ваших других пластырей не подходит. Это действительно ПРАВИЛЬНЫЙ ответ. Вы хотите, чтобы ваше приложение никогда не открывало консоль. Кроме того, вы хотите иметь возможность открывать форму в любое время. Так что вы просто вызываете форму, когда хотите. т.е. наша форма вызывается, когда пользователь щелкает правой кнопкой мыши значок на панели задач и выбирает настройки. ЭТО ПРАВИЛЬНЫЙ ОТВЕТ .

Вы можете использовать FreeConsole API, чтобы отсоединить консоль от процесса:

(конечно, это применимо, только если у вас есть доступ к исходному коду консольного приложения)

Хотел консоль не показывать. Хотя FreeConsole делает то, что говорит его название, это не мешает Windows отображать консоль до ее вызова. Затем скомпилируйте проект как приложение Windows, а не консольное приложение Для справки, это именно то, что мне нужно, спасибо. Это также именно то, о чем и требует название :) Итак, в интересах других путешественников Google, +1 Вдобавок [DllImport("kernel32.dll")] static extern bool AllocConsole(); позволяет легко запускать с консоли из стандартного приложения Win32

Если вас интересует вывод, вы можете использовать эту функцию:

Он запускает указанную программу командной строки, ожидает ее завершения и возвращает вывод в виде строки.

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

Но если все, что вам нужно, - это запускать процесс до его завершения, например, вызывая его из планировщика задач, тогда служба неудобна, поскольку продолжает существовать. В некоторых ситуациях очень удобно изменить тип вывода на Windows Application вместо альтернативного ProcessWindowStyle как скрытого.

Добавьте это в свой класс, чтобы импортировать файл DLL:

А затем, если вы хотите скрыть это, используйте эту команду:

А если хотите показать консоль:

[DllImport ("user32.dll")] статический extern bool ShowWindow (IntPtr hWnd, int nCmdShow); [DllImport ("kernel32.dll")] статический extern IntPtr GetConsoleWindow (); const int SW_HIDE = 0; const int SW_SHOW = 5;

Я знаю, что отвечаю не совсем то, что вы хотите, но мне интересно, правильный ли вы вопрос задаете.

Почему бы вам не использовать:

служба Windows
создайте новый поток и запустите свой процесс на этом

Похоже, это лучшие варианты, если все, что вам нужно, - это запустить процесс.

Существует множество сценариев, в которых запуск служебного консольного приложения является вполне законным. В моем случае требуется отдельный процесс из-за модели клиент / сервер, которую использует программное обеспечение, над которым я работаю. Создание нового потока не всегда решает проблему. Бывают случаи, когда вам просто не нужно раздражающее окно в фоновом режиме. Кроме того, что, если у вас есть process.start в цикле, вы не сможете выполнить какую-либо работу, так как окна консоли всплывают прямо перед вами. Я запускаю служебные консольные приложения без окон из Планировщика заданий. Нет необходимости в обслуживании и нет родительского процесса, из которого можно разветвлять поток. Эти приложения записывают в журнал событий, если требуется дополнительный вывод.

Хотя, как сказано в других ответах, вы можете изменить «Тип вывода» на «Приложение Windows», имейте в виду, что это будет означать, что вы не можете использовать, Console.In поскольку он станет NullStreamReader.

Console.Out и, Console.Error похоже, все еще работает нормально.

Ты серьезно? Зачем кому-то использовать, Console.In когда нет консоли, чтобы что-то вводить? Откуда взять что-нибудь, к чему можно получить доступ Console.In ? В этом нет никакого смысла. Другими словами: Это совершенно очевидно и логично , что Console.In является NullStreamReader в данном случае. @RobertS. Может быть, трубка. Т.е. вывод другой программы. Это был мой случай использования, когда я это обнаружил.

Основываясь на ответе Адама Марковица выше, у меня сработало следующее:

У меня есть общее решение:

Просто включите этот класс в свой проект и позвоните Magician.DisappearConsole(); .

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

Я делаю это для бота Discord, который вечно работает в фоновом режиме моего компьютера как невидимый процесс. Это было проще, чем заставить работать TopShelf. Пара руководств по TopShelf не удалась, прежде чем я написал это с некоторой помощью кода, который я нашел в другом месте. ;П

Я также попытался просто изменить настройки в Visual Studio> Project> Properties> Application для запуска в качестве приложения Windows вместо консольного приложения, и что-то в моем проекте помешало этому скрыть мою консоль - возможно, потому что DSharpPlus требует запуска консоли при запуске. . Я не знаю. Какой бы ни была причина, этот класс позволяет мне легко отключить консоль после ее появления.

У меня есть консольное приложение, и я хотел бы запустить его как службу Windows. VS2010 имеет шаблон проекта, который позволяет присоединить консольный проект и построить сервис Windows. Я не хотел бы добавлять отдельный сервисный проект и, если возможно, интегрировать сервисный код в консольное приложение, чтобы консольное приложение оставалось как один проект, который мог бы работать как консольное приложение или как служба Windows, если он запускается, например, из командной строки с помощью переключателей.

Почему бы вам просто не создать временный сервисный проект и не скопировать биты, которые делают его сервисным?

Я обычно использую следующую технику для запуска того же приложения, что и консольное приложение или как служба:

Это ожидаемо - ваша служба будет работать как отдельный процесс (так будет отображаться в диспетчере задач), но этот процесс будет контролироваться системой (например, запускаться, останавливаться, перезапускаться в соответствии с настройками службы). Если вы запустите его как консольное приложение, вы не увидите службу. Вся цель этого кода состоит в том, чтобы позволить вам запускать его либо как консольное приложение, либо как службу. Для запуска в качестве службы сначала необходимо установить ее (используя класс ServiceInstaller - см. Ссылку MSDN выше - или installuitil.exe), а затем запустить службу из панели управления. ServiceInstaller - это просто служебный класс для работы со службами Windows (немного похожий на утилиты installutil.exe или sc.exe). Вы можете использовать его для установки того, что вы хотите в качестве службы, ОС не заботится о типе проекта, который вы используете. Просто добавьте ссылку в свой проект в System.ServiceProcess, и вы сможете использовать приведенный выше код

Я имел большой успех с TopShelf .

Из консоли диспетчера пакетов (Nuget):

Обратитесь к примерам кода, чтобы начать.

TopShelf также заботится об установке службы, которая может сэкономить много времени и удаляет стандартный код из вашего решения. Чтобы установить .exe в качестве службы, просто выполните следующее из командной строки:

Вам не нужно подключать ServiceInstaller и все такое - TopShelf сделает все за вас.

Привет, я получаю это: - "Не удалось установить пакет 'Topshelf 4.0.1'. Вы пытаетесь установить этот пакет в проект, который нацелен на '.NETFramework, Version = v4.5', но пакет не содержит никаких ссылки на сборки или файлы содержимого, совместимые с этой платформой. " что здесь не так? пожалуйста, вы можете пролить больше света на myservice.exe и из какого каталога вы собираетесь открыть командную строку @Izuagbala myservice.exe - это созданное вами консольное приложение, в которое загружается TopShelf, как показано в примере кода.

Итак, вот полное прохождение:

Создать новый проект консольного приложения (например, MyService)
Добавьте две ссылки на библиотеку: System.ServiceProcess и System.Configuration.Install
Добавьте три файла, напечатанные ниже
Создайте проект и запустите «InstallUtil.exe c: \ path \ to \ MyService.exe»
Теперь вы должны увидеть MyService в списке сервисов (запустите services.msc)

Program.cs

MyService.cs

MyServiceInstaller.cs

Это работает очень хорошо, обратите внимание, что, как говорит @snytek, если вы используете base 64, убедитесь, что вы используете правильный каталог. Кроме того, если вы делаете то же самое, что и я, и забыли переименовать службу в нечто иное, чем «MyService», обязательно удалите службу, прежде чем вносить изменения в код.

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

Одна сборка библиотеки, которая делает всю работу. Тогда есть два очень очень тонких / простых проекта:
тот, который является командной строкой
тот, который является службой Windows.

Это, как я делал это в течение многих лет - служба в значительной степени имеет Start() и Stop() методы , и приложение консоли имеет петлю. Если не считать фреймворк , такой как TopShelf , это лучший вариант согласен с этим ответом наиболее. использование инструментов 3D-вечеринок для простых решений делает ненужным обслуживание будущего

Если вы создадите рабочую службу из Visual Studio 2019, она предоставит вам практически все, что вам нужно для создания службы Windows из коробки, что также необходимо изменить в консольном приложении, чтобы преобразовать его в службу Windows.

Вот изменения, которые вам нужно сделать:

Установите следующие пакеты NuGet

Измените Program.cs для реализации, как показано ниже:

и добавьте Worker.cs, куда вы поместите код, который будет выполняться операциями службы:

Когда все готово и приложение успешно собрано , вы можете использовать sc.exe для установки exe своего консольного приложения в качестве службы Windows с помощью следующей команды:

Ты можешь использовать

И это появится в списке услуг. Я не знаю, правильно ли это работает, хотя. Служба обычно должна прослушивать несколько событий.

Однако есть несколько сервисных оболочек, которые могут запускать любое приложение как реальный сервис. Например, Microsoft SrvAny из комплекта ресурсов Win2003

Как вы говорите, служба exe должна будет общаться с Windows. +1 за ссылку на SrvAny Нет необходимости в установщиках и прочем: просто используйте эту командную строку: sc create MyServiceName binPath = "c: \ path \ to \ service \ file \ exe"

Сначала я встраиваю консольное приложение в решение для службы Windows и ссылаюсь на него.

Затем я делаю консольный класс программы приложения общедоступным.

Затем я создаю две функции в консольном приложении

Затем в самой службе Windows я создаю экземпляр Программы и вызываю функции Start и Stop, добавленные в OnStart и OnStop. Увидеть ниже

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

это в основном то, что сказал JonAlb в предыдущем ответе, но спасибо за пример кода

Возможно, вам следует определить, что вам нужно, насколько я знаю, вы не можете одновременно запускать ваше приложение как консоль или службу с командной строкой. Помните, что служба установлена, и вы должны запустить ее в диспетчере служб, вы можете создать новое приложение, которое запустит службу или запустит новый процесс, выполняющий ваше консольное приложение. Но как вы написали

"сохранить консольное приложение как один проект"

Чтобы улучшить свой сервис, есть еще одна вещь, которую вы можете сделать, но это не быстро и / или легко, это использование доменов приложений и создание библиотек DLL для загрузки / выгрузки. В одном вы можете запустить новый процесс с помощью консольного приложения, а в другом dll вы можете просто добавить функциональность, которую должен выполнять сервис.

Вы должны разделить функциональность на класс или классы и запустить их через одну из двух заглушек. Заглушка консоли или служебная заглушка.

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

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

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

Я не прочитал это полностью, но эта статья, кажется, сдать в правильном направлении.

Я использую класс обслуживания, который следует стандартному шаблону, предписанному ServiceBase , и использую помощников для легкой отладки F5. Благодаря этому данные сервиса определяются в сервисе, что облегчает их поиск и управление жизненным циклом.

Читайте также: