Comments 47
Пустой проект создать не сложно…
Убивают нюансы)
Например, удаление сервиса всё также через одно место, если открыто окно сервисов — получите ошибку.
Отладка это наше всё… Если есть ошибка в процедуре(не синтаксическая, конечно, например, неверный ип для коннекта), то без поллитры не разберёшся, вызвалась ли эта процедура вообще(разумеется, возмоности чуть более вменяемой отладки требуют покупки Ultimate лицензии). И прочее, прочее…
Убивают нюансы)
Например, удаление сервиса всё также через одно место, если открыто окно сервисов — получите ошибку.
Отладка это наше всё… Если есть ошибка в процедуре(не синтаксическая, конечно, например, неверный ип для коннекта), то без поллитры не разберёшся, вызвалась ли эта процедура вообще(разумеется, возмоности чуть более вменяемой отладки требуют покупки Ultimate лицензии). И прочее, прочее…
Для «вменяемой отладки» достаточно писать вменяемые логи и расставлять вменяемые ассерты.
О, поколение, испорченное дебаггерами…
О, поколение, испорченное дебаггерами…
UFO just landed and posted this here
То есть точки остановки как бы не нужны?
Вообще интерактивный дебаг как бы не нужен. Точнее, он очень нужен для посмертного вскрытия корок, и для отладки чужого и очень плохого кода.
А свой код можно и нужно изначально писать так, чтобы пользоваться правильными техниками отладки. Без всяких там break points и прочего.
А свой код можно и нужно изначально писать так, чтобы пользоваться правильными техниками отладки. Без всяких там break points и прочего.
Золотые слова! Особенно при многопоточке: ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%B9%D0%B7%D0%B5%D0%BD%D0%B1%D0%B0%D0%B3
Коммент, достойный уважения)
На моей памяти(могу и раскопать тот специфический проектик на C#), даже запись лога в том варианте просто кричала о том, что процедура не была вызвана.
Тоесть, функция вида
{
запись в лог 1;
…
строка с ошибкой в создании объекта;
…
запись в лог 2;
return ...;
}
Не делала записей в лог-файл вообще. Attach-to-proccess также показывал пропуск этой процедуры. При исключении же строки с ошибкой процедура выполнялась.
Отладили как раз созданием консольного приложения, где эта процедура всё-таки вызывалась, хоть и с ошибкой.
На моей памяти(могу и раскопать тот специфический проектик на C#), даже запись лога в том варианте просто кричала о том, что процедура не была вызвана.
Тоесть, функция вида
{
запись в лог 1;
…
строка с ошибкой в создании объекта;
…
запись в лог 2;
return ...;
}
Не делала записей в лог-файл вообще. Attach-to-proccess также показывал пропуск этой процедуры. При исключении же строки с ошибкой процедура выполнялась.
Отладили как раз созданием консольного приложения, где эта процедура всё-таки вызывалась, хоть и с ошибкой.
А вы лог флашили?
Вообще, первое правило — писать вывод логов и ассерты сразу и везде. Это, кроме всего прочего, еще и дополнительные аннотации к коду, проще читать потом будет. Нельзя проверки просто навешать потом на код вокруг подозрительного места — ведь реально ошибка может быть где-то еще, далеко от того, где все сломалось.
Вообще, первое правило — писать вывод логов и ассерты сразу и везде. Это, кроме всего прочего, еще и дополнительные аннотации к коду, проще читать потом будет. Нельзя проверки просто навешать потом на код вокруг подозрительного места — ведь реально ошибка может быть где-то еще, далеко от того, где все сломалось.
Что более забавно, изначально, лог флашился только на событиях опаснее некоторого уровня и при остановке сервиса, впрочем, исправление не привело прямиком к успеху.
После работы посмотрю, что там конкретно было, но повторюсь — функция, согласно дебаггеру, вообще не вызывалась.
Кстати, «опасный» код был в блоке try, у которого в catch также была запись в лог, что добавило к ловле блох как минимум час.
После работы посмотрю, что там конкретно было, но повторюсь — функция, согласно дебаггеру, вообще не вызывалась.
Кстати, «опасный» код был в блоке try, у которого в catch также была запись в лог, что добавило к ловле блох как минимум час.
Все эти симптомы говорят, что реальная ошибка где-то вовсе за пределами этого блока кода. Довольно редкий случай в .NET, правда, если unmanaged-вызовами особо не баловаться.
Эта строка создавала подключение к SIMATIC OPC Server.
Соседнее же присоединение к PostgreSQL при неверных параметрах выдавало вполне вменяемое исключение.
Мой опыт в .NET довольно скромен, потому склонен довериться Вашему мнению.
Всё же, убивали в сервисах именно нюансы, и с первой попытки запустить что-либо сложнее приведённого примера может выйти не у каждого.
Соседнее же присоединение к PostgreSQL при неверных параметрах выдавало вполне вменяемое исключение.
Мой опыт в .NET довольно скромен, потому склонен довериться Вашему мнению.
Всё же, убивали в сервисах именно нюансы, и с первой попытки запустить что-либо сложнее приведённого примера может выйти не у каждого.
Более того, для вменяемой отладки нужно несколько способов запуска приложения: один — запуск в виде сервиса, двугой — в виде стандартного консольного приложения, в котором вся отладка прекрасно работает. Запустил приложение без ключа — стандартное консольное приложение, запустил с ключом /service — сервис.
Есть и вариант наоборот (для .NET и Java и вообще любой рефлексивной среды работает идеально) — встроить в приложение консоль для отладки. REPL какого либо скриптового языка, к которому можно подцепиться telnet-ом, и не прерывая работы выполнить произвольный код в контексте приложения.
Подскажите, пожалуйста, где про это поподробнее почитать можно.
Ну, вот примерчик реализации (для Java и Clojure):
clojure101.blogspot.com/2009/05/creating-clojure-repl-in-your.html
clojure101.blogspot.com/2009/05/creating-clojure-repl-in-your.html
UFO just landed and posted this here
По собственному опыту — легче сначала разрабатывать в виде консольного приложения, затем оформлять его в виде сервиса.
А что, разве нельзя сделать «Attach to process»? Там ведь не так сложно было. Я правда сервисы не писал давно (около двух лет), поэтому могу не помнить подробностей. Просто запускаешь службу, делаешь «Attach to process», выбираешь показывать все процессы, выбираешь нужный и можно дебажить пошагово. VS была, если не ошибаюсь, 2008 Prof, но думаю такая возможность и в express есть (не могу проверить).
Можно, это работает. Проблема в том что так вы не сможете отдебажить стартап код.
Ну я в свое время (давно уже) писал такое: bitbucket.org/jonie/winsrvdebughelper
Просто давите F5 в проекте и получаете окно управления проектными сервисами (их может быть не один в рамках одного проекта)… конечно, надо учитывать права из под кого будет запускаться сервис в дебаге и в реальности (как раз в примере по ссылке производится запись в корень C:\ что даст сбой при ограниченном аккаунте).
ЗЫ: у автора может быть проблемы с вылетанием при записи логов при сильно ограниченном аккаунте под кем стартует сервис…
Просто давите F5 в проекте и получаете окно управления проектными сервисами (их может быть не один в рамках одного проекта)… конечно, надо учитывать права из под кого будет запускаться сервис в дебаге и в реальности (как раз в примере по ссылке производится запись в корень C:\ что даст сбой при ограниченном аккаунте).
ЗЫ: у автора может быть проблемы с вылетанием при записи логов при сильно ограниченном аккаунте под кем стартует сервис…
Не знаком с тонкостями .Net приложений, но в плюсах просто декларировал время старта сервиса порядка 15 секунд и при старте Sleep секунд на 10, за это время вполне успеваешь приаттачить отладчик.
Извращение конечно, но ошибку поймать удалось (не правильно прописал одно из полей).
Извращение конечно, но ошибку поймать удалось (не правильно прописал одно из полей).
Слишком «для школьников»
Для отладки я использую такую схему:
Всю логику сосредотачиваю в dll, которую подключаю к сервису.
Плюс к этому я создаю обычный винформс аппликейшн, к которому тоже подрубаю эту dll.
Вот тут разворачивается простор для дебага.
А описанный мною в статье шаблон сервиса отлично подходит как раз для подключения и использования какой-нить библиотеки.
Всю логику сосредотачиваю в dll, которую подключаю к сервису.
Плюс к этому я создаю обычный винформс аппликейшн, к которому тоже подрубаю эту dll.
Вот тут разворачивается простор для дебага.
А описанный мною в статье шаблон сервиса отлично подходит как раз для подключения и использования какой-нить библиотеки.
Вообщето для отладки достаточно скомпилировать проект. Инсталировать сервис, и при запуске сервиса в течении 30 секунд присоединится к процессу сервиса, ну и ставить бряки в сырцах сервиса. Вуаля, дебаг аналогичный как и дебаг простого приложения.
А если нужно дебажить прямо со старта сервиса, и не хочется вставлять таймауты, что бы успеть приаттачится, то можно первой коммандой сделать.
Debugger.Launch();
Debugger.Launch();
Это тоже работает. А можно как делает 99% человечества, а именно в конскольке запускать.
Вот тут я отписал мой метод habrahabr.ru/blogs/net/102826/#comment_3198530
Чем проще, тем лучше 8)
Чем проще, тем лучше 8)
И кстати, метод OnStart в сервисе должен отработать за указанные 30 секунд, иначе получим ошибку запуска сервиса.
У меня тоже есть пост на тему написания сервисов. В посте показан поллинг-сервис с саморегистрацией и запуском из консоли — эти две фичи у меня фигурируют во всех сервисах.
Вообщем, имхо, хабру нужны более техничные статьи — тема-то большая.
Вообщем, имхо, хабру нужны более техничные статьи — тема-то большая.
Поддерживаю, все сервисы пишу с саморегистрацией и возможность работы просто из командной строки — запустить без инсталяции и чтобы так же выполнял свои задачи. Во время разработки очень удобная штука, не нужно устанавливать сервис, а просто отлаживаешь как обычное консольное приложение.
Для этого даж проект специальный есть github.com/topshelf/topshelf
проще воспользоваться прогами вроде AppToService, которые любой приложение умеют запускать как службу.
вот способ от microsoft по запуску любого приложения как службы: www.py-my.ru/post/4bfb3c691d41c846bc000044
«Многие из нас сталкиваются с такой задачей, когда нужно запускать своё приложение при запуске компьютера. Конечно можно поместить ярлык в автозагрузку, но как-то это неправильно. Да к тому же если комп перегрузился, а пользователь не залогинелся, то и ваше приложение тоже не запустится. „
А вы путаете сервис и приложение. Приложение при запуске компьютера надо запускать автораном или аналогами вроде шедулера и так далее. А сервис — это отдельный класс программ, выполняющих свои собственные задачи.
В частности, сервис надо писать так, чтобы он умел работать в Non-interactive (без окон, консоли, без всего), и умел корректно закрываться по соответствующим командам системы. Приложению на это начхать.
А вы путаете сервис и приложение. Приложение при запуске компьютера надо запускать автораном или аналогами вроде шедулера и так далее. А сервис — это отдельный класс программ, выполняющих свои собственные задачи.
В частности, сервис надо писать так, чтобы он умел работать в Non-interactive (без окон, консоли, без всего), и умел корректно закрываться по соответствующим командам системы. Приложению на это начхать.
Переписанная статься из мсдн с кучей ошибок, что может быть более достойно главной?
UFO just landed and posted this here
Я вообще давно написал вот такой универсальный скелетон для службы, который можно положить в common.dll и использовать во всех своих проектах, там же и пример использования, не претендую на оригинальность, код вбирает в себя все что было в туториалах, плюс то что понадобилось для себя
pastebin.com/yje1MzWA
pastebin.com/yje1MzWA
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Пишем свой Windows service