3

I'm relatively new to C# so please bear with me. I am looking for a logging solution for my project (desktop small business application). I know this has been asked a zillion times, but I have some additional requirements and questions.

Is there a logging tool for .NET which is (all of the following):

-reliable (logging everything that was send to logger, even the very last exception before the crash, log4net doesn't guarantee that)
-fast (not blocking the caller -> asynchronous)
-thread-safe (can be called from multiple threads at the same time and write to one file)

-encrypts log files (or allows totally custom logging - writes only what it gets, no additional information)

-free

Well, that's my list of requirements. Do you know any tolls which fit? I've read about log4net, but it seems old (uses .NET 2.0 and mainly reinvents the wheel), nlog sounds promising as it is asynchronous, yet again I think it can't encrypt. Also I don't know if both of them are totally thread safe.

Should I just write my own little logger? I thought about making a logging thread, a list (or queue) of logs, and using locking append to the list appropriate logs, logging thread would convert (probably to string, or some parts to string) log objects, encrypt them and save them to a file as soon as possible.

What do you think I should do? Thank you for your ideas and answers.

Ben
  • 2,435
  • 6
  • 43
  • 57

2 Answers2

3

You could use Microsoft Enterprise Library 5.0 logging . You'd can use the MSMQ targeting to get it completely Asynchronous. With the encryption piece you have a couple of options.

Create your own listener which will encrypt messages sent or you can encrypt it before you send. A couple of nice aspects of creating your own listener

  • Sender doesn't have to "know" how to encrypt. This means if your encryption policy changes you have just have to code it in one object.
  • Relatively easily to configure different behavior depending on environment.

The major downside of using ent lib is the configuration in general can be a PIA if you get complicated with it.

Conrad Frix
  • 51,984
  • 12
  • 96
  • 155
2

NLog is still maintained, on the contrary of Log4Net. And Yes, it IS thread-safe. See my post on that.
You just have to know how to use it correctly according to your use case scenario.

As of Encryption, NLog is very expandable and you can write your own log target that encrypts the content before sending it to files (or other). There are lots of Libraries that offer such a utility (RSA Among others).

You would seamlessly encrypt content in an Encryption Service just before sending it to the log utility per se. Here is a starter code sample, taken from this post

var provider = new System.Security.Cryptography.RSACryptoServiceProvider();
provider.ImportParameters(your_rsa_key);

var encryptedBytes = provider.Encrypt(
System.Text.Encoding.UTF8.GetBytes("Hello World!"), true);

string decryptedTest = System.Text.Encoding.UTF8.GetString(
provider.Decrypt(encryptedBytes, true));
Community
  • 1
  • 1
Mehdi LAMRANI
  • 11,289
  • 14
  • 88
  • 130
  • Thank you for your post. I checked your post on multi-threading with NLog, but I'm not sure I got it right, you can use (to send logs) one logger across multiple threads without locking? It seems like quite some work/time (cuz I don't know Nlog) to expand NLog with encryption functionality. I think it would take me less time to realize my own logger. Do you maybe know if my idea about logger is bad, problematic, would be slow, noticably worse than Nlog? – Ben May 11 '11 at 13:27
  • Creating your own logger is a bad idea, believe me. There are plenty of posts detailing why this is a bad idea, among others the fact that you will realize little by little that you have more and more needs, and each time you will have to add functionalities to your own logger. So this would be reinventing the wheel. Nlog is pretty straightforward and the learning curve is not that steep. I have pushed it to its limits in mutli-threading and that is why I had to tweak things more that the basic stuff. And, no, you dont have to use explicit locking if you use it right. – Mehdi LAMRANI May 12 '11 at 16:47
  • Using RSA directly on text is an improper use. RSA is considered secure only when the input is sampled randomly. Typically the solution is to use a hybrid cryptosystem using both a symmetric and and asymmetric algorithm, where the asymmetric algorithm operates on random data or like-random data and the symmetric algorithm operates on the actual user data. – bchurchill Jun 20 '17 at 15:45