лучший подход для каркаса ведения журнала / обработки ошибок для приложения C # .NET v3.5? (корпоративная библиотека / log4net /?)

Question

Я работаю над WinNET-приложением .NET v3.5 и хотел бы использовать некоторую поддержку:

a) ведение журнала (для файла и, возможно, для событий Windows)

b) структура обработки ошибок / обработки исключений - для помощи в различении сообщений, которые могут быть показаны пользователю, и обработаны в коде и зарегистрированы

в) дополнительный бонус будет заключаться в том, как регистрировать / накапливать серьезные ошибки для меня через веб-сервис на стороне сервера (аналогично Firefox, когда он просит вас сообщить о проблемах с обратной связью разработчикам) - однако, если это удваивает сложность Я прошу отказаться от этого требования

Вещи, которые я знаю, включают:

• log4net - кажется популярным, но не уверен, поможет ли это с моим требованием b)
• корпоративная библиотека - на которую я смотрел, однако она кажется немного тяжелой (например, излишняя)

спасибо

Answer 1

Я предвзят, конечно. Но сделайте себе одолжение и посмотрите на мою структуру ведения журнала . Это намного проще в использовании, чем некоторые другие фреймворки. Он также поставляется с примером приложения Windows, которое отображает журналы в режиме реального времени. Существует также плагин Visual Studio для просмотра журналов. Также легко отправлять логи в веб-сервис или куда угодно. (У меня есть пример кода для входа в Twitter, например.)

Answer 2

Раньше я использовал оба, но в конце концов отбросил EntLib в пользу log4net, так как имхо проще, проще в настройке и использовании. В любом случае, обе библиотеки будут в порядке, это скорее личное оправдание для данного проекта.

Answer 3

Log4net мой любимый. Высоко настраиваемый, простой в использовании.

Что касается веб-службы для агрегирования отчета об инцидентах в журнале, я столкнулся с той же самой проблемой, и в итоге я сам создал службу: bugcollect.com . Вы можете скачать log4net, добавленный с сайта, и убедиться в этом. Служба выполняет анализ отчетов и объединяет аналогичные отчеты в сегменты. Вы можете настроить уведомления по электронной почте при отправке нового отчета, нового сегмента или нового источника. Вы также можете настроить ответ для группы, и этот ответ будет возвращен приложению при обнаружении аналогичного инцидента, например, при указании пользователю загрузить более новую версию. Служба имеет интерфейс RESTful для отправки отчетов, но для .Net, Java, log4net и log4j есть бесплатных клиентских библиотек , доступных для загрузки. Вы можете попробовать бесплатную учетную запись с ограниченными возможностями или ввести промо-код BETA для ознакомления с полной функциональностью.

Answer 4

+ 1 для log4net.

Что касается (b), я склонен определять свои собственные пользовательские исключения (все они происходят из одного и того же базового класса, например, «BusinessException»), которые вызываются BLL для ошибок, которые необходимо сообщить пользователю (ввод данных нарушает бизнес-правило). , авторизация пользователя не удалась, ...). Если BLL развернут как веб-служба, такие исключения включаются в ошибку SOAP с кодом ошибки клиента (SOAP 1.1) / отправителя (SOAP 1.2).

Затем на уровне пользовательского интерфейса любое BusinessException или FaultException с FaultCode.IsSenderFault = true указывает, что сообщение об ошибке должно отображаться для конечного пользователя. Любые другие исключения регистрируются, и конечному пользователю показывается общее сообщение («что-то плохое произошло»).

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

Относительно (c) вы могли бы написать пользовательское приложение log4net, которое отправляет серьезные ошибки вашему веб-сервису (возможно, асинхронно через MSMQ).

EDIT

В ответ на комментарий я не знаю ни одного стороннего фреймворка, который бы это делал; мы делаем это с помощью очень легкой внутренней структуры (которая также имеет другие базовые вещи, такие как тонкий API-модель провайдера, вокруг log4net, так что наш внутренний код не зависит явно от log4net, и мы сможем переключиться на другую каркас журналирования, если появится лучшее или если наше приложение развернуто на сайтах, где администраторы предпочитают другое).