.Net Logger (Write your own vs log4net/enterprise logger/nlog etc.)

Question

I work for an IT department with about 50+ developers. It used to be about 100+ developers but was cut because of the recession.

When our department was bigger there was an ambitious effort made to set up a special architecture group.

One thing this group decided to do was create our own internal logger. They thought it was such a simple task that we could spend recources and do it ourselves. Now we are having issues with performance and difficulty viewing the logs generated and some employees are frustrated that we are spending recources on infrastructure stuff like this instead of focusing on serving our business and using stuff that already exists like log4net or Enterprise Logger.

Can you assist me in listing up reasons why you should not create your own .net logger.

Also reasons for why you should are welcome to get a fair point of view :)

Answer 1

if your logging solution has such special requirements that an off the shelf solution doesn't work, than maybe making a custom version might be worthwhile.

If this is the argument though, one could also consider downloading an opensource framework and try to customize it.

Answer 2

I would take a different approach. How about first introducing a common interface to your own library such as Common Infrastructure Libraries (http://netcommon.sourceforge.net/). Then you can gradually move all projects over to that interface and if your own library is not up to the job for large projects then simply switch over to one of the open source frameworks (or even a commercial solution).

HTH Alex

Answer 3

I use a custom logging API that uses a provider model design, that allows an external logging framework to be plugged in. I have developed providers for Log4Net, EntLib and the System.Diagnostics.Trace loggers.

This is essentially the same concept as the Common Infrastructure Libraries.

This means that internal developments do not have an explicit dependency on an external logging framework, yet you can still benefit from all the features of your favorite logging framework. In practice we usually use Log4Net except for customers who are already using EntLib.

Answer 4

• It cost money.
• It was done so many time before.
• You are not as special as you think. If you are, then do something about it.
• Maybe you are not as smart as you think.
• Are you over staffed? Yet?

Answer 5

In my last job, almost all the infrastructure was written by us instead of using some of-the-shelf products. (and by "all the infrastructure" I mean ALL of it - Logging, Messaging, Database, Containers of so on).

One of the biggest disadvantages of it was that it made us spend most of our time working on the things that are irrelevant to the end-user instead of adding more features.

from that job I've learned to always focus on the things your product was meant to solve. is your company developing loggers? will the quality of your logger influence your customer more than another feature? I don't think so.

You have a limited budget and manpower - use it wisely. Don't reinvent the wheel. I'm sure that your company and your customers will benefit if you'll focus your attention on things that they need.

in my current project I'm using NHibernate as ORM framework instead of an in-house one that is in use in other projects. instead of fixing bugs in the old ORM framework, my focus is on the main roadmap of the project. furthermore, NHibernate has it's own roadmap which means that additional features will come without much resources from my company.

Answer 6

I disagree with those who see people reinventing wheels everywhere. A wheel could be a database server, an operating system or a programming language. However things like a ORM framework or this log4net thing aren't in the market enough time to be considered wheels. Many of these products have a short life cycle, they are replaced by new approaches, just consider how many ORM frameworks have you seen, and then comes Microsoft and launches LINQ. Logging is not a solid discipline you can learn and it is very platform dependent. So considering using a logging framework which could come obsolete (log4net vs nlog), wasting your time learning it, does not exclude the option of build your own logging. I have done this with ORM mapping, for me has been better building a few ORM classes than learning nHybernate.

Answer 7

I wrote my own one because I thought (A) it is based on a TraceListener which is a standard .NET class and (B) it is little and simple to use and maybe because I wanted to write one anyway.

But now I am using NLog in my new projects and replacing it in some old ones!

Am I wrong? Both works for me fine and the reason for using NLog for me was that I wanted a feature that needed an almost rewriting of my custom TraceListener. It turned out a 1 or 2 hour tutorial with a sample app was cheaper for me. This is not a universal situation; but helps with having a more clear image about logging problems.