Using NLog 2.0 in Silverlight or how I became an open source

It all started quite banal - with the fact that I needed logging in my Silverlight project.

Under the “adult” .NET, I have always used NLog from Jarek Kowalski. And why not log4net, many of you will be asked.
All, of course, quite subjective, but oh well.

The taste and color, markers and clay, but NLog is simply better. In order not to be unsubstantiated, I will quote a few killer criteria ...

• Convenient configuration. After log4net - like a breath of fresh air.
  ')
  
• The library is written by a professional .NET platform for the .NET platform, it can be seen in the source code and architecture. The same log4net, judging by the source code, is a banal Java code recompiled for .NET, with fixed syntax errors (after all, C # is not exactly Java;)
  
  
• The project is actively developing. The first beta of NLog 2.0 with the support of all .NET stacks, including Mono, Silverlight and CF, was released the other day. The same log4net, judging by the check-in-am, stopped its development in the shaggy 2003.

On this comparison we finish and proceed directly to the solution.

1. Download NLog 2.0 beta 1 , install.
   
   
2. Add to our Silverlight project a link to NLog.dll. I have Productivity Power Tools for VS.NET 2010, there is such a nice new template for adding links to assemblies, it automatically finds the correct link to the Silverlight version of NLog.
   
   
3. Add to the project New Item -> NLog | Console NLog Config. We get a new file in the project called NLog.config. This is the static configuration of our logging. Make sure the Build Action of this file is in Content mode. I tried to throw it into resources, then read and initialize the configuration at the start. It turns out that NLog does it all for us. The main thing is that the config-file should be in the project root, and the Build Action should be> Content. As I said, the configuration is static, i.e. NLog.config is stored in the xap-archive and changes, without unnecessary gestures, is not subject. There is no question of any automatic update of the logging configuration when changing NLog.config, as is the case with desktop .NET applications.
   
   
4. Logging to a file from a simple Silverlight application is not possible. Another thing, if we have full-trust, but this mode is in my mind initially abnormal. Therefore, we will log onto the remote machine over the network. The client will be the Log2Console client, which is widely known in narrow circles of users of log4net.
   
   

So, we write:

static readonly Logger _log = LogManager.GetCurrentClassLogger();

and then:

_log.Debug(" {0} NLog", DateTime.Now);


Here I was a little disappointed. It turns out that Silverlight does not support UDP-sockets. Accordingly, UDP-Receiver from Log2Console, which previously could have been listening to NLog, is useless in Silverlight. Silverlight supports TCP-sockets, but TCP-Receiver is not detected in Log2Console. Well, I thought, look for something else in the spirit of Log2Console, but with TCP support.

By the way, the native NLog-ovsky NLogViewer turned out to be so buggy that even the alpha version doesn’t call the language ...

So, it remains to write the basement yourself.

Having rolled up my arms higher, tightening the belt and the laces tighter, zatariv drinking and provision, I plunged into the Mariana trench of programming ...

Total for an hour TCP-Receiver for Log2Console was ready. This is what the configuration for TCP-Receiver looks like in NLog.config:

<target name="network" xsi:type="NLogViewer" address="tcp4://deepblue:4505" />


But here a little disappointment awaited me again. It turns out that Silverlight cannot just happen, without a special invitation to transfer data to your ports. For a start, it is available only with three dozen ports (4502-4532), and those are not simple, but require permission. Namely, the target machine on port 943 must host a special ClientAccessPolicy.xml file, in which it is written who will get the nuts.

Having found the source of this Policy-server from someone on blogs, compiling and running it, I was pleased to find in Log2Console my test messages sent from the Silverlight application.



At this attentive reader will say that it is time to relax. But no, the next day, constantly forgetting to start this Policy-server, I deprived myself of records in Log2Console and was angry.

Do kolih / zyat / Enough / Genug! - I decided and added another Receiver to the Log2Console, namely SilverlightClientAccessPolicy-Receiver. Log2Console saves the configuration of the running receivers and restores them when restarted, which is very convenient. Now I remember starting the policy server and am not angry :)



Here, it seems, you can already begin to relax ...

But it was not there. I wrote to the author of Log2Console, explained the problem to him and suggested a solution. I hit the hands with Ctrl + Enter, and then I noticed that Log2Console uses WPF ... Not that I was strongly opposed ... But Log2Console - an application under WinForms, WPF needs a fifth wheel as a dog.

In short, the same evening, with surgical intervention from Win32CodePack, I cut out the functionality of the Windows 7 Taskbar ...
Along the way, LINQ was also thrown away (two Min / Max methods were used) ...

And so, Log2Console began to support .NET 2.0, and I, as it is not cool, became an open source contributor ...

An updated version of Log2Console with support for Silverlight and the .NET Framework 2.0 can already be downloaded here . NLog project site is here .

Here and the tale is over, and who listened - well done!