Началось все достаточно банально — с того, что мне понадобился logging в моем проекте на Silverlight.
Под «взрослым» .NET-ом я всегда пользовался NLog-ом от Ярека Ковальского. А почему не log4net, спросят многие из вас.
Все, конечно, достаточно субъективно, ну да ладно.
На вкус и цвет, фломастеры и пластилин, но NLog просто-напросто лучше. Чтобы не быть голословным, приведу несколько убойных критериев…
На этом сравнения закончим и перейдем непосредственно к решению.
а потом:
Здесь меня ожидало небольшое разочарование. Оказывается, Silverlight не поддерживает UDP-sockets. Соответственно, UDP-Receiver из Log2Console, которым раньше можно было слушать NLog, в Silverlight бесполезен. Silverlight поддерживает TCP-sockets, но TCP-Receiver в Log2Console не обнаружен. Хорошо, подумал я, поищем еще чего-нибудь в духе Log2Console, но с поддержкой TCP.
К слову, родной NLog-овский NLogViewer оказался настолько глюкавым, что его даже альфа версией назвать язык не поворачивается…
Стало быть, остаетсяподвал написать самому.
Засучив рукова повыше, затянув ремень и шнурки потуже, затарившись питиём и провизионом, я погрузился в марианскую впадину программирования…
Итого за час TCP-Receiver для Log2Console был готов. Вот так выглядит конфигурация для TCP-Receiver-а в NLog.config:
Но здесь меня снова ожидало небольшое разочарование. Оказывается, Silverlight не может просто так, без особого приглашения лить данные на ваши порты. Для начала, доступно только с три десятка портов (4502-4532), да и те не простые, а требуют разрешения. А именно, целевая машина на 943 порту должна хостить специальный ClientAccessPolicy.xml файл, в котором прописано, кому достанутся орешки.
Найдя у кого-то в блогах исходники этого Policy-сервера, скомпилировав и запустив, я с удовольствием обнаружил в Log2Console свои тест-сообщения, посланные из Silverlight приложения.
На этом внимательный читатель скажет, что наступило время расслабиться. Но нет, на следующий день, постоянно забывая запустить этот Policy-сервер, я лишал себя записей в Log2Console и злился.
До коли/Досыть/Enough/Genug! — решил я и добавил в Log2Console еще один Receiver, а именно SilverlightClientAccessPolicy-Receiver. Log2Console сохраняет конфигурацию запущенных ресиверов и при перезапуске восстанавливает их, что очень удобно. Теперь я не забываю запустить Policy-сервер и не злюсь :)
Вот тут вроде бы уже и можно начинать расслабляться…
Но не тут-то было. Я списался с автором Log2Console, объяснил ему проблему и предложил решение. Ударили порукам Ctrl+Enter-ам, и тут я заметил, что Log2Console использует WPF… Не то, чтобы я был сильно против… Но Log2Console — приложение под WinForms, WPF там нужен как собаке пятое колесо.
Короче говоря, в тот же вечер, хирургическим вмешательством из Win32CodePack мной был вырезан функционал Windows 7 Taskbar…
По ходу дела был так же выброшен LINQ (использовалось два метода Min/Max)…
И таким образом, Log2Console стал поддерживать .NET 2.0, а я, как не крути, стал контрибутором-опенсорсником…
Обновленную версию Log2Console с поддержкой Silverlight и .NET Framework 2.0 уже можно скачать тут. Сайт проекта NLog здесь.
Вот и сказке конец, а кто слушал — молодец!
Под «взрослым» .NET-ом я всегда пользовался NLog-ом от Ярека Ковальского. А почему не log4net, спросят многие из вас.
Все, конечно, достаточно субъективно, ну да ладно.
На вкус и цвет, фломастеры и пластилин, но NLog просто-напросто лучше. Чтобы не быть голословным, приведу несколько убойных критериев…
- Удобная конфигурация. После log4net — как глоток свежего воздуха.
- Библиотека написана профессионалом .NET платформы для .NET платформы, это видно по исходникам и архитектуре. Тот же log4net, судя по исходникам, это банально перекомпилированный под .NET явовский код, с исправленными ошибками синтаксиса (ведь C# не совсем Java ;)
- Проект активно развивается. На днях вышла первая бета NLog 2.0 c поддержкой всех .NET стеков, включая Mono, Silverlight и CF. Тот же log4net, судя по check-in-ам, остановился в своем развитии в лохматом 2003 году.
На этом сравнения закончим и перейдем непосредственно к решению.
- Скачиваем NLog 2.0 beta 1, устанавливаем.
- Добавляем в наш Silverlight проект ссылку на NLog.dll. У меня стоят Productivity Power Tools для VS.NET 2010, там такой симпатишный новый диаложек для добавления ссылок на сборки, автоматом находит правильную ссылку на Silverlight-версию NLog.
- Добавляем в проект New Item -> NLog | Console NLog Config. Получаем в проекте новый файл под названием NLog.config. Это статическая конфигурация нашего логгирования. Убедитеcь, что Build Action у этого файла стоит в режим Content. Я было попытался закинуть его в ресурсы, потом при старте прочитать и проинициализировать конфигурацию. Оказывается, NLog делает это все за нас. Главное, config-файл должен находится в корне проекта, а Build Action -> Content. Как я уже сказал, конфигурация статическая, т.е. NLog.config хранится в xap-архиве и изменениям, без лишних телодвижений, не подлежит. Ни о каком автоматическом обновлении конфигурации логгирования при изменении NLog.config, как в случае с настольными .NET приложениями, речи не идет.
- Логирование в файл из простого Silverlight приложения невозможно. Другое дело, если у нас full-trust, но этот режим по моему разумению изначально ненормален. Поэтому будем логировать на удаленную машину по сети. Клиентом будет служить широко известный в узких кругах пользователей log4net клиент Log2Console.
static readonly Logger _log = LogManager.GetCurrentClassLogger();
а потом:
_log.Debug("Привет {0} из NLog", DateTime.Now);
Здесь меня ожидало небольшое разочарование. Оказывается, Silverlight не поддерживает UDP-sockets. Соответственно, UDP-Receiver из Log2Console, которым раньше можно было слушать NLog, в Silverlight бесполезен. Silverlight поддерживает TCP-sockets, но TCP-Receiver в Log2Console не обнаружен. Хорошо, подумал я, поищем еще чего-нибудь в духе Log2Console, но с поддержкой TCP.
К слову, родной NLog-овский NLogViewer оказался настолько глюкавым, что его даже альфа версией назвать язык не поворачивается…
Стало быть, остается
Засучив рукова повыше, затянув ремень и шнурки потуже, затарившись питиём и провизионом, я погрузился в марианскую впадину программирования…
Итого за час TCP-Receiver для Log2Console был готов. Вот так выглядит конфигурация для TCP-Receiver-а в NLog.config:
<target name="network" xsi:type="NLogViewer" address="tcp4://deepblue:4505" />
Но здесь меня снова ожидало небольшое разочарование. Оказывается, Silverlight не может просто так, без особого приглашения лить данные на ваши порты. Для начала, доступно только с три десятка портов (4502-4532), да и те не простые, а требуют разрешения. А именно, целевая машина на 943 порту должна хостить специальный ClientAccessPolicy.xml файл, в котором прописано, кому достанутся орешки.
Найдя у кого-то в блогах исходники этого Policy-сервера, скомпилировав и запустив, я с удовольствием обнаружил в Log2Console свои тест-сообщения, посланные из Silverlight приложения.
На этом внимательный читатель скажет, что наступило время расслабиться. Но нет, на следующий день, постоянно забывая запустить этот Policy-сервер, я лишал себя записей в Log2Console и злился.
До коли/Досыть/Enough/Genug! — решил я и добавил в Log2Console еще один Receiver, а именно SilverlightClientAccessPolicy-Receiver. Log2Console сохраняет конфигурацию запущенных ресиверов и при перезапуске восстанавливает их, что очень удобно. Теперь я не забываю запустить Policy-сервер и не злюсь :)
Вот тут вроде бы уже и можно начинать расслабляться…
Но не тут-то было. Я списался с автором Log2Console, объяснил ему проблему и предложил решение. Ударили по
Короче говоря, в тот же вечер, хирургическим вмешательством из Win32CodePack мной был вырезан функционал Windows 7 Taskbar…
По ходу дела был так же выброшен LINQ (использовалось два метода Min/Max)…
И таким образом, Log2Console стал поддерживать .NET 2.0, а я, как не крути, стал контрибутором-опенсорсником…
Обновленную версию Log2Console с поддержкой Silverlight и .NET Framework 2.0 уже можно скачать тут. Сайт проекта NLog здесь.
Вот и сказке конец, а кто слушал — молодец!