Вопросы о службе Windows, которая в основном простаивает - PullRequest
4 голосов
/ 22 декабря 2011

У меня есть служба Windows, которая предназначена для выполнения двухминутного задания один раз в день. Оставшиеся 23:58 дня, он просто сидит и выглядит симпатично.

Мой вопрос касается в первую очередь простоя: лучше использовать Timer.Tick или Thread.Sleep? Есть ли какая-либо разница между ресурсами, которые они используют?

Во-вторых, во время этого простоя, если кто-то завершает работу Службы Windows, нужно ли прерывать эти незанятые потоки, чтобы программа полностью закрылась, или «Завершение работы» справится со мной?

В-третьих, я лаю не на том дереве с помощью службы Windows? Казалось бы, имеет смысл поместить запись в планировщик задач Windows, но я не смог найти никакого способа сделать это с помощью InstallShield, который мы используем для развертывания нашего продукта. Есть идеи получше?

Ответы [ 6 ]

3 голосов
/ 22 декабря 2011

FWIW, InstallShield не имеет встроенных возможностей для определения запланированных задач, но поддерживает пользовательские действия VBScript, C ++ и InstallScript.Все эти опции поддерживают вызов интерфейсов автоматизации COM, и Microsoft предоставляет планировщик задач через серию объектов планировщика задач.

Справочник по планировщику задач

Работа ЦП в стороне, WindowsСервис, работающий все время, также потребляет память.Фактически, каждая версия Windows имеет меньше сервисов.

Почему Windows 8 использует намного меньше памяти, чем Windows 7

3 голосов
/ 22 декабря 2011

Если вы запускаете фоновый поток с ThreadPool.QueueUserWorkItem, я думаю, что вы могли бы иметь Thread.Sleep там, и когда вы закрываете сервис, вам не нужно ничего делать с ним.Я думаю, что Timer Tick будет автоматически создавать потоки для вас, когда он тикает, так что вам придется делать еще меньше, если вы используете это (из двух таймер будет, я думаю, соответствует тому, что вы хотите достичь лучше, так будетлучший выбор).

Это определенно похоже на то, что было бы лучше сделать планировщиком, как вы говорите.Я не знаю, можете ли вы сделать это непосредственно в InstallShield, но, возможно, вы могли бы создать небольшое консольное приложение, которое вы запускаете из установщика, которое на основе аргумента командной строки либо обращается к API расписания задач Windows - http://msdn.microsoft.com/enus/library/windows/desktop/aa383614(v=vs.85).aspxзарегистрировать себя или выполнить задание, которое вы хотите достичь (т.е. -install - установить его в расписании, ни один аргумент не будет делать то, что вам нужно, один раз в день).

Я думаю, что это C ++API, так что вы можете сделать немного p / invoke или, лучше, просто иметь некоторый управляемый C ++ в классе libaray и ссылаться на него из консольного приложения на основе ac #.

2 голосов
/ 22 декабря 2011

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

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

Я бы, вероятно, пошел с библиотекой планирования, такой как Quartz.Net , если бы мне пришлось создавать приложение с более продвинутыми требованиями к планированию.

2 голосов
/ 22 декабря 2011

Я бы порекомендовал Службу Windows, так как в противном случае вы просто дублируете ее функциональность.

Если InstallShield не поддерживает добавление в планировщик задач, то вы можете заставить InstallShield запускать пакетный скрипт или небольшой.net app после установки, чтобы добавить его в планировщик задач?

2 голосов
/ 22 декабря 2011

Я бы использовал Timer.Tick.Thread.Sleep блокирует поток, и вы не можете красиво прервать поток, когда закрываете свой сервис.

1 голос
/ 22 декабря 2011

Если у вас нет приложения для планирования, такого как autosys, лучше использовать службу Windows, также я не вижу никакого вреда в thread.sleep, она предназначена для приостановки приложения и использования 0% ЦП

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