Привет.

Поделитесь пожалуйста какой-нибудь заготовкой для Win службы.

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

В частности у меня такой вопрос.

Если требуется, чтобы OnStart лишь запускал поток, а потом выходил из функции максимально скоро, то как быть, если при инициализации уже рабочего функционала (вот в запущенном потоке) возникает ошибка, и дальше вообще продолжать нет смысла ?
Если, на пример, файла конфигурации нет.
Ведь мы уже завершили OnStart, сообщили, что все ок - а рабочий поток через секунду проблемы обнаружил. Тут логичней выглядит типичная ситуация с SCM, когда запускаемая служба сразу падает и SCM говорит об этом.

А если ошибка всплывает только секунд через 40 (например таймаут WCF операции при начальном обращении к удаленной службе) ?

Интересует, как TPL, со своими Токенами-отмены, вписывается в схему OnStart, OnStop.

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

PS. Эх. А хорошо бы было, если бы существовал некий репозиторий кода, где бы хранились "базовые кирпичики" часто используемого функционала. Чтобы рутина была написана 1 раз профессионалами, а потом бери и используй :) Сколько типичных ошибок удалось бы избежать в программах :)
Мачты мачты.

MsSql_StudyМачты мачты.

и мечты тоже :)

Алексей КНу из этого потока записать причину остановки в системный журнал и остановить службу?

Да, это конечно. Но мне почему-то кажется, что было бы идеально, чтобы программа падала при загрузке в SCM. А тут выйдет, что основной поток загрузится успешно.

Я сам при тестировании сужу о работоспособности сервиса по тому, загрузился он в SCM или нет :) Если SCM сразу сообщает, что "Служба не запустилась" сразу понятно, что произошла ошибка.

А так, выйдет, что все загрузится мгновенно, пока там дополнительный поток будет считывать конфигурацию.

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

PS. Если дополнительный поток обнаружит проблему и остановит службу, даже если это произойдет во время загрузки в SCM - ошибка же не вылетит ?


Алексей К,

Спасибо за ссылку на Вашу программу. Она у меня уже есть, изучал ее, хотя пока ничего не прикрутил в свои программы, у меня все проще гораздо. Но я даже не знал, что она умеет в виде службы запускаться :) Возможно даже видел, что она умеет это, но тогда не придал значения - не нужно было. А сейчас об этом не вспомнил.

Спасибо гляну.

Алексей КMsSql_StudyНу просто это будет чуть запутывающе. Человеку нужно лезть в папку службы и смотреть, не появилась ли новая запись в логе. Не удобно же !Тогда может ServiceBase.RequestAdditionalTime Method в OnStart попробовать?

Может быть.
Выходит так, что моя задумка противоречит типичной картине служб. Мне кажется, что все должно происходить в OnStart, чтобы сразу показать - есть ли проблемы или нет.
А не заставлять человека залезать в логи, и смотреть не появилась ли нужная запись ошибки.
Если в один лог пишется и Trace, Info и ошибки, то факт создания лога лишь покажет, что были стандартные Трейсы. Т.е. не получится просто удалить файлы лога, и по их появлению судить об ошибке.
Вы чувствуете какая головная боль получается при проверки, запустилась ли служба ? :)
Я об этом и думал, создавая тему.
Хотя конечно, разумные программисты для трейсов и ошибок используют разные логи.

Вообще. Можно просто обновить экран состояний служб в SCM (F5) и мы увидим, что наша служба просто остановлена ? Тоже, как вариант понять, что произошла ошибка загрузки :) В принципе хороший и простой вариант.


RequestAdditionalTime интересная функция. Когда читал МСДН и обдумывал как делать службу, думал об этом методе. Но, он не вписывается в стандартные рекомендации, потому появились сомнения, и создал эту тему.

Так что выходит, нужно в OnStart сразу просить минут 15 дополнительного времени, а если уложимся гораздо быстрее, просто завершим функцию OnStart и все ?
По идее, сюда нормально попадет таймаут WCF. SCM будет терпеливо ждать загрузки хоть 20 минут. Хотя нам хватит и 1 минуты на таймаут.
По крайней мере такой подход позволит ЧЕТКО видеть - запустилась ли все таки служба или нет !

Или все же проще оставить все стандартно:)

Алексей К,

Да само собой. 2 режима - на время отладки консоль проще, чем глючная служба :)

Я говорю уже про этап эксплуатации. Когда служба по какой то причине может погибнуть при загрузке.

Как вариант решения проблемы: завести глобальную переменную string с текстом ошибки.

Метод OnStart запускает рабочий поток, и затем ждет 5-9 секунд . Если за это время рабочий поток обнаружит ошибку, не совместимую с жизнью службы, он пишет ошибку в глобальную переменную и устраняется.
OnStart через 9 секунд проверят наличие ошибки. Если есть, то пишем лог, и генерируем исключение - SCM сообщает пользователю, что служба не запустилась, подробности он увидит в логе.
Если ошибки нет в течении 9 секунд, то с огромной вероятностью все работает успешно - за 9 секунд можно успеть провести базовую проверку, конфигурацию. Разве что таймауты всяких там WCF могут нарушить этот алгоритм.

Таким образом мы нарушаем стандартное правило "OnStart за 2 секунды", но зато покажем пользователю что служба погибла. Удобно любому тестировщику и внедренцу, да и простмоу пользователю.

Алексей КТут :-)


Ну да, пишется лог клиентского места :)
Ваша программа вообще очень крута. Я еще долго буду постигать ее :) Хорошо склееный WCF и TPL и плюс WPF.

PS. Вот только не нашел в вашей программе MVVM + Гриды для изучения :)
Как я понял, это самая болезненная часть этой связки вообще.

Алексей К,

Ну да. Вроде бы по MVVM+DataGrid часто задают вопросы. Все эти сложности с выделениями строк и передачей команд...
Гриды в программах обычная вещь. А вот примеров с MVVM нету :)

Алексей К,

Ну вроде бы есть тут на форуме темы с вопросами "как выяснить по какой колонке щелкнули через MVVM" и в той теме вроде бы проскакивало, что есть заморочки.

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

:)

Изопропилэто заблуждение

Ну я предложил вариант решения. OnStart специально ждет 10 секунд. Если за это время в глобальной переменной не появится текст ошибки, то выходим с успехом. Иначе логируем ошибку, бросаем исключение чтобы SCM дал знать пользователю, что что-то произошло.
Можно даже сократить это время, если заставить рабочий поток подавать Ивент, что он завершил инициализацию. Тогда, в большинстве случаев, нам даже не нужны будут эти 10 секунд. OnStart завершится, когда ему сообщат, что инициализация прошла успешно.

Это позволит в подавляющем числе случаев (если только ошибка не возникнет уже после этих 10 секунд) сообщить пользователю запустилась служба или нет. Просто и ясно, без необходимости лезть в логи.
Хотя с другой стороны. Можно просто удалить лог с ошибками и при запуске службы видеть по самому факту создания файла, что что-то сломалось.

Да и в принципе ничего не мешает после запуска служб обновить их список в SCM по F5 и будет видно, что наша служба все же остановлена. Но это потребует от пользователя лишних телодвижений :)

Ну а вообще, как сказал Алексей К - службы работают сами по себе.
Предлагаемая мной разработка лишь облегчит жизнь внедренцам и тестировщикам когда они пытаются локализовать проблему, и перебирают настройки перезапуская службу и видя как она падает. Но в 99% случаев этот функционал даже не пригодится конечно :)

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

В общем забудьте. Данной темы не существует. Здесь никого нет. Вы ничего тут не читали. Это просто фантазии. Ау, тут есть кто ? Зачем я разговариваю сам с собой интересно )