I think I might be missing the point of having a logging framework for your application. In all the small apps I've always written a small "Logging" class and just pass log messages to a method in it which is written to a file.
What is the purpose of a 3rd party logging framework like log4net? Is it thread safety with logging write operations or am I missing something?
you might want to switch to log to a db for some message, or an alerting system that pages the poor person on support
More importantly though, most logging frameworks allow you to specify the loglevel of different classes so you dont need to cut a new binary each time you want more/less logging (that verbose logging for the bug you just spotted in production)
Log4Net's site has more detail
Depending on how smart your own logging system implementation is.
In java, if you want to inherit log types, etc., it might be too much hassle and you'd prefer a third-party tool like Log4J. I assume there are similar things for C#. Similarly if you want to determine log level from the command line.
If you just want to route all your System.out and control whether they are printed whenever you compile, your own logger would do just fine.
In a word: flexibility. Log4xxx gives you the ability to do different logging levels, to log different modules of code to different files, and you can depend on it to be dependable no matter what strange situation it hits (what will your logger do if the disk is out of space?)
Something the other comments have omitted: if there's already a library that does what you want, it saves you having to write the code.
Possibly you're playing semantics here: to me, a "logging framework" typically is little more than a class that writes log messages to a file... so what you've done is write your own logging framework. Given that you have done so, there is obviously some point in "using a Logging framework"!
Ultimately you're going to need to make sure it handles concurrent logging correctly (locking the output stream), can log to a file, syslog, etc., can do log rolling, and so on. You can save yourself that effort by using someone else's well-tested code.
Logging frameworks offer flexibility and prevent you from reinventing the wheel. I know it's brain-dead simple to append to a file in any modern language, but does your home grown logger have multiple targets? Can you turn logging on and off at run-time? Why risk a flat tire when these wheels are available for free?
That's an excellent question.
The first reason is "why not?" If you are using a logging framework, then you'll reap the maintainability benefits of using something already packaged.
The second reason is that logging is subtle. Different threads, sessions, classes and object instances may all come into play in logging, and you don't want to have to figure this problem out on the fly.
The third reason is that you may find a performance bottleneck in your code. Figuring out that your code is slow because you're writing to a file without buffering or your hard drive has run out of disk space because the logger doesn't rollover and compress old files can be a pain in the neck.
The fourth reason is that you may want to append to syslog, or write to a database, or to a socket, or to different files. Frameworks have this functionality built in.
But really, the first answer is the best one; there's very little benefit to writing your own, and a whole bunch of drawbacks.