We use NLog 2.0 in Silverlight or how I became an open source

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

Under the "adult" .NET, I always used the NLog from Jarek Kowalski. And why not log4net, many of you will ask.
Everything, of course, is quite subjective, but oh well.

It tastes and color, felt-tip pens and plasticine, but NLog is simply better. In order not to be unsubstantiated, I will give a few killer criteria ...

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

We’ll finish this comparison and go directly to the solution.

1. Download NLog 2.0 beta 1 , install.
   
   
2. Add a link to NLog.dll in our Silverlight project. I have Productivity Power Tools for VS.NET 2010, there is such a pretty new dialog for adding links to assemblies that automatically finds the correct link to the Silverlight version of NLog.
   
   
3. Add to the project New Item -> NLog | Console NLog Config. We get in the project a new file called NLog.config. This is the static configuration of our logging. Make sure that the Build Action for this file is in Content mode. I tried to drop it into resources, then at start read and initialize the configuration. It turns out that NLog does it all for us. The main thing is that the config file should be located in the root of the project, and Build Action -> Content. As I said, the configuration is static, i.e. NLog.config is stored in the xap archive and is not subject to change without unnecessary gestures. There is no question of any automatic updating 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 is if we have full-trust, but this mode, in my opinion, is initially abnormal. Therefore, we will log to a remote machine over the network. The client will be the Log2Console client, widely known in the narrow circles of users of log4net .
   
   

So, we write: and then: Here I was expecting a little disappointment. It turns out that Silverlight does not support UDP-sockets. Accordingly, the UDP-Receiver from Log2Console, which used to be able to listen to NLog, is useless in Silverlight. Silverlight supports TCP-sockets, but no TCP-Receiver was found in Log2Console. Well, I thought, let's 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 does not turn out to call it a language ... Therefore, it remains to write the basement yourself. Rolling up my arm higher, tightening my belt and laces tighter, stocking up with food and provisions, I plunged into the Marianas depression of programming ...

static readonly Logger _log = LogManager.GetCurrentClassLogger();



_log.Debug("Привет {0} из NLog", DateTime.Now);










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




But here again, a little disappointment awaited me. It turns out that Silverlight cannot just pour data on your ports without a special invitation. For starters, only three dozen ports are available (4502-4532), and those are not simple, but require permission. Namely, the target machine on port 943 must host a special ClientAccessPolicy.xml file, which says who gets the nuts.

After finding the source code for this Policy server from someone on my blogs, compiling and running it, I was pleased to find my test messages sent from Silverlight applications in Log2Console.



At this, the attentive reader will say that it is time to relax. But no, the next day, constantly forgetting to run this Policy-server, I stripped myself of entries in the Log2Console and became angry.

Before coli / Finish / Enough / Genug! - I decided and added another Receiver to the Log2Console, namely SilverlightClientAccessPolicy-Receiver. Log2Console saves the configuration of running receivers and restores them upon restart, which is very convenient. Now I do not forget to start the Policy server and I'm not angry :)



Here, it seems, it is already possible to start relaxing ...

But it wasn’t there. I contacted the author of Log2Console, explained the problem to him and proposed a solution. Shook handsCtrl + Enter, and then I noticed that Log2Console uses WPF ... Not that I was strongly opposed ... But Log2Console is an application for WinForms, WPF is needed like a fifth wheel for a dog.

In short, that evening, I removed the functionality of Windows 7 Taskbar from Win32CodePack ...
In the process, LINQ was also thrown out (two Min / Max methods were used) ...

And so, Log2Console began to support .NET 2.0, and I Like it or not, I’ve become an open source contributor ... An

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

This is the end of the tale, and whoever listened is well done!