Каковы лучшие практики при выполнении процесса как сервиса окон?
Есть ли любые вещи заботиться о при выполнении процесса или исполняемого файла как сервис. Вещи как тихий вход. Критические сценарии сообщения об ошибке? и т.д.? Как Вы обрабатываете его?
5 ответов
Для отчетов о критических ошибках вы ограничены использованием стандартных настроек службы (в свойствах установленной службы), либо делаете что-то сами. Это может быть простой файл журнала, который регистрирует неожиданные ошибки (используя AppDomain.UnhandledException для их отлова и регистрации), использование журнала событий Windows для регистрации подобной информации, или другой процесс, следящий за службой на предмет ошибок (т.е. остановки службы) и оповещающий кого-либо.
В Microsoft есть статья под названием "Introduction to Windows Service Applications", которая является хорошим общим введением в создание служб в .Net.
Некоторые другие моменты о разработке служб Windows из моего опыта:
- Службе Windows дается около 30 секунд на запуск. После этого Windows сообщит, что она запущена неправильно. Это означает, что вам нужно убедиться, что ваш метод
OnStartслужбы запускает новый поток для запуска службы, а затем возвращается. - Не ожидайте никакого взаимодействия с пользователем (т.е. окон сообщений, подтверждений), поскольку служба работает "без головы" (т.е. без пользовательского интерфейса), поэтому вы не можете ожидать, что пользователь будет взаимодействовать с ней.
- Проверьте учетную запись, под которой будет работать служба, чтобы убедиться, что вы не запускаете ее от имени пользователя с излишне высокими привилегиями безопасности.
- Широко используйте протоколирование (например, log4net), чтобы вы могли видеть, что делает служба во время выполнения, а также диагностировать любые ошибки (путем протоколирования трассировки стека).
- Убедитесь, что вы используете правильную версию InstallUtil (т.е. 32 или 64 бит) для установки службы. Еще лучше позволить службе установить себя с помощью ManagedInstallerClass.InstallHelper.
Не показывать окна сообщений / диалоговые окна.
Имейте в виду, что ваше приложение обычно не запускается под той же учетной записью, что и вошедший в систему пользователь. Поэтому, если пользователь может получить доступ к какому-либо файлу / каталогу, это не означает, что служба может делать то же самое.
Убедитесь, что у вас есть какая-то система оповещения, которая сообщит вам, если служба перестает работать, например отправьте электронное письмо себе или в какой-нибудь почтовый ящик.
- Обязательно используйте API трассировки / ведения журнала для получения диагностической информации. Журнал событий, файлы журналов, база данных, что угодно ... Просто имейте где-нибудь информацию для устранения неполадок.
- Отслеживайте / регистрируйте как можно раньше и чаще. Нет ничего более неприятного, чем необходимость вносить изменения в код, просто чтобы добавить диагностическую трассировку.
- Помните об утечке памяти. При написании приложения, которое будет перезапускаться каждый день или запускаться как запланированная задача, мы иногда немного ленивы. Помните, что эта служба должна тщательно убирать за собой. Правильно используйте предложение using со всеми IDisposables.
- Не забудьте ключевое слово volatile в вашей переменной STOP! Боже мой, это меня каждый раз достает.
Если это имеет смысл, не забудьте реализовать событие Pause. Обрабатывайте все исключения, чтобы при сбое происходил корректный сбой.