Используем NLog 2.0 в Silverlight или как я стал опенсорсником

Началось все достаточно банально — с того, что мне понадобился logging в моем проекте на Silverlight.

Под «взрослым» .NET-ом я всегда пользовался NLog-ом от Ярека Ковальского. А почему не log4net, спросят многие из вас.
Все, конечно, достаточно субъективно, ну да ладно.

На вкус и цвет, фломастеры и пластилин, но NLog просто-напросто лучше. Чтобы не быть голословным, приведу несколько убойных критериев…

• Удобная конфигурация. После log4net — как глоток свежего воздуха.
  
  
• Библиотека написана профессионалом .NET платформы для .NET платформы, это видно по исходникам и архитектуре. Тот же log4net, судя по исходникам, это банально перекомпилированный под .NET явовский код, с исправленными ошибками синтаксиса (ведь C# не совсем Java ;)
  
  
• Проект активно развивается. На днях вышла первая бета NLog 2.0 c поддержкой всех .NET стеков, включая Mono, Silverlight и CF. Тот же log4net, судя по check-in-ам, остановился в своем развитии в лохматом 2003 году.

На этом сравнения закончим и перейдем непосредственно к решению.

1. Скачиваем NLog 2.0 beta 1, устанавливаем.
   
   
2. Добавляем в наш Silverlight проект ссылку на NLog.dll. У меня стоят Productivity Power Tools для VS.NET 2010, там такой симпатишный новый диаложек для добавления ссылок на сборки, автоматом находит правильную ссылку на Silverlight-версию NLog.
   
   
3. Добавляем в проект New Item -> NLog | Console NLog Config. Получаем в проекте новый файл под названием NLog.config. Это статическая конфигурация нашего логгирования. Убедитеcь, что Build Action у этого файла стоит в режим Content. Я было попытался закинуть его в ресурсы, потом при старте прочитать и проинициализировать конфигурацию. Оказывается, NLog делает это все за нас. Главное, config-файл должен находится в корне проекта, а Build Action -> Content. Как я уже сказал, конфигурация статическая, т.е. NLog.config хранится в xap-архиве и изменениям, без лишних телодвижений, не подлежит. Ни о каком автоматическом обновлении конфигурации логгирования при изменении NLog.config, как в случае с настольными .NET приложениями, речи не идет.
   
   
4. Логирование в файл из простого 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, объяснил ему проблему и предложил решение. Ударили по рукам 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 здесь.

Вот и сказке конец, а кто слушал — молодец!