Запланированное консольное приложение против службы Windows? Когда уместно использовать каждый

Question

Я только что прочитал это: В чем преимущество разработки приложения как службы Windows? , но я все еще не уверен, когда использовать службу Windows.

У меня есть пара задач, которые нужно запускать с интервалами (то есть каждые 5 минут). Какой тип проекта я должен использовать? Есть ли примеры типов приложений, которые должны быть службами Windows?

Answer 1

Для любой запланированной задачи я обычно рекомендую Службу Windows по следующим причинам:

• Служба Windows будет работать, даже если пользователь не вошел в ПК (будет работать, даже если сервер сидит в приглашении для входа в систему) (*** Примечание - это может зависеть от используемой версии Windows) .
• Служба может работать как учетные записи высокого уровня, такие как Сетевая служба или Локальная система, или Пользователь - они имеют больше возможностей настройки в этом отношении
• Сервис также поставляется с опциями запуска, остановки, перезапуска и приостановки во время работы (иногда)
• Вы также можете настроить условия сбоя для служб, например, в случае сбоя, он автоматически перезапускается

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

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

Что касается ошибки с таймером - если вы читаете отчет об ошибке на сайте MS, вы можете увидеть, что он вызван, когда вы вызываете «Stop» внутри события Timer_Elapsed. Ответ на этот вопрос прост - не называйте стоп. Вместо этого оберните все это в проверку для логического значения IsRunning и запускайте только если IsRunning имеет значение false. Даже если бы не было проблемы с таймером, вам все равно нужно это сделать, потому что таймер может перезапуститься во время вашего выполнения, если ваше выполнение займет больше времени, чем ваш интервал таймера.

В любом случае, я все еще думаю, что использование запланированных задач является слабым решением и дает мне воспоминания о Windows 95.

Answer 2

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

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

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

Важным фактором также является планировщик заданий - очень надежный и гибкий планировщик событий. Крайне маловероятно, что вы могли бы написать планировщик, который был бы более надежным и мог обрабатывать капризы времени и планировать на основе триггеров. На самом деле существует ряд вопросов об использовании таймеров для планирования задач в службах на этом сайте, и примечательно, что количество ответов (включая некоторые из «правильных» ответов), которые имеют низкое качество или совершенно неверные.

РЕДАКТИРОВАТЬ: Интересно также отметить, что политика Microsoft отходит от использования служб для действий на основе задач. Если вы проверите Vista, Win2K8 и Win7, вы увидите растущий список запланированных задач специального назначения, которые выполняют обслуживание системы и многие системные службы.

Answer 3

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

По моему опыту, запланированные задания чрезвычайно надежны. Я не помню ни одного сбоя, и я поддерживаю около полудюжины различных запланированных задач, которые выполняются в любом месте - ежедневно или каждые 15 минут. (Не было никаких сбоев, но все они были проблемами с кодом или конфигурацией. И были зарегистрированы, и уведомления были отправлены. Проблема НИКОГДА не была с инфраструктурой планирования задач.)

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

Мой самый большой плюс в развертывании. Для консольных приложений просто опубликуйте EXE-файл в нужной целевой папке. Для служб Windows вам нужно остановить службу (с помощью net.exe), удалить службу (с помощью InstallUtil.exe), подождать (у меня спит развертывание в течение 25 секунд), опубликовать EXE-файл и затем сделать все наоборот (установить , начать).

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

Answer 4

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

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

Answer 5

У меня есть несколько запланированных задач Windows, которые выполняются ежечасно на рабочем веб-сервере. Они совсем не надежны. Они работают в Windows 2003 Server под определенной учетной записью компьютера. Большую часть времени они работают отлично, но иногда они не запускаются, а иногда заканчивают работу раньше, чем заканчивают работу.

Отчасти это может быть связано с тем, что они являются скриптами vbscript и тем, как они написаны, но я видел запланированные задачи с WS FTP Pro (коммерческим программным обеспечением FTP), которые ведут себя так же.

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

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

Answer 6

Это типичный случай для службы Windows, IMO.

Answer 7

В большинстве случаев я бы предпочел обслуживание Windows.
Одна хорошая вещь при использовании запланированных задач:
Все использованные ресурсы освобождаются после завершения запланированной задачи.

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