Последнее время стал отслеживать всякие форумы и другие хранилища знаний в области WCF, вроде такой http://www.gotdotnet.ru/forums/19/. Удивился тому, что люди просто напросто не знают как выяснить какая ошибка мешает работе WCF сервиса. Причем проблема скорей не в том, что люди не хотят выяснить ошибку, они просто не знают как это сделать. Поэтому сейчас я буду играть в детектива, говорить «элементарно, Ватсон», пуская круги дыма из трубки … В общем сейчас расскажу простые вещи, которые можно сделать, чтобы выяснить в чем ошибка.
Включаем отображение ошибок для IIS
Для asp.net разработчиков, да и для всех более менее адекватных разработчиков дело привычное и вроде бы понятно что делать – включить отображение ошибок. Значит добавляем в web.config следующие строчки:
<customErrors mode="RemoteOnly" />
Или
<customErrors mode="Off" />
И сразу все становится понятно:
Скажу еще, что отображение ошибок полезно в случае, когда сервис просто не запускается. Возможно из-за ошибок, связанных с компиляцией, правами доступа и еще 1000 ошибок, которые мешают нормальному запуску сервиса.
Включаем трассировку WCF
Подробней о трассировке WCF можете посмотреть тут. Как правило, долго сидеть с конфигураций не хочется. Прописывать здоровый кусок конфига дело неблагодарное. Благо, есть такая интереная утилитка, как WCF Service Configuration Editor. Вызывается она либо из меню Tools студии, либо из контекстного меню Solution Explorer на конфиге. Утилитка работает и вне контекста студии, так что можно использовать и там, где установить студию нельзя. Нас в данной утилите интересует раздел Diagnostics и его подраздел - Tracing.
Нас в большинстве случаев интересует две настройки:
1. Непосредственно включение Tracing.
2. Log file – файл, куда будет писаться лог.
Файлик svclog, который будет записан в результате работы сервиса содержит детальную информацию о работе сервиса. При этом, его можно открыть, используя достаточно удобный просмотрщик (регистрируется по умолчанию для расширения svclog).
Для файлов трейса есть интересная особенность, они находятся в монопольном доступе у службы, поэтому прежде, чем их просматривать с помощью утилиты нужно закрыть хост сервиса. В случае с IIS – перезапустить группу приложений, что в некоторых случаях невозможно.
Отладка
Если перечисленные выше простые способы не помогают, приходится использовать тяжелую артиллерию, в данном случае – отладку. Однако и она не всегда помогает. Пример тому – ошибка в недрах WCF, когда просто напросто невозможно подхватить ошибку отладчиком. Такое случается как правило, когда переписываются стандартная инфраструктура WCF, как то свой сериализатор, или система аутентификации. В данных случаях бывает полезным включение трейсов.
В итоге
Приведенные способы выяснения причины неполадки вашего сервиса прекрасно сочетаются друг с другом и могут быть использованы совместено. Все зависит от их разумного использования.
Удачной отладки!!! ;)
Posted via email from Комуникликабельность
Прихожу постепенно к мысли, что WCF просто напросто не предназначен для того, чтобы передавать большие куски данных. А Streamed, который в нем реализован – это просто костыль, который покрывает часть задач, но не ложится в общую идею WCF. Вообще, иногда складывается впечатление, что в WCF все построено по «кусочному принципу». Функционал реализован мелкими кусками, как будто разработчики пытались «растянуть» архитектуру на как можно больший пласт задач, а она (архитектура) в силу технических ограничений никак не позволяла это сделать. Вот пример, того, что WCF не покрывает ряд задач аутентификации при Streamed режиме. Я кстати об этом же писал недавно.
Попробовал поставить