.Net Logging
-
Agreed. I just threw that in there for illustrative purposes
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
IMO there are at least 2 advantages to those frameworks: - Separating the decision of what to log from the decision of "where" to place the log - Allowing you to change your mind post installation (via a watched external config file) Been using both web systems for almost 20 years. I've been continually glad for the ability to diagnose problems in the field in a straightforward way using mechanisms that are publicly documented and widely understood. Countless real bugs have been quickly identified and resolved thanks to this instrumentation.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
What happens when you start the second instance of the program? What happens when you run it as a service? How do you look at the log remotely, while the program is running locally? Windows already has event logging that work well, using WMI. Remotely accessible, fits in with enterprise operations management frameworks, no file droppings in local directories, no need to reinvent the wheel. Log4Net et al. are solutions that fit problems when logging expands to larger enterprise systems. Silly log files quickly break down when complexity increases.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
I AGREE 10,000% !!!! Excellent post! I did pretty much exactly what you did.. I looked at those logger and went "WTF.. this is WAY overcomplicated so I wrote something MUCH simpler very similar to yours.
-
Nish Nishant wrote:
That said, some of these logging frameworks kept adding features and now are unnecessarily complex, and may have reached a saturation point of over-engineering.
Adobe is doing the same thing with Photoshop now. I hope it doesn't get worse, that's been one of my favorite apps for so many years. If it goes to crap it'll be a sad, sad day for computerland. :((
Jeremy Falcon
I still use PhotoShop 7 (2002) -- it has never suddenly changed how it works. Nor has Office 2003.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Funny co-incidence! I _just_ got done dealing with existing log4net code that wasn't set up to work with multiple threaded entities (the way it was being used in our project) ...so my choices were to: 1) learn the overly complex log4net API and add add even more external dependencies to our several DLLs that were using it 2) write about 30 lines of code to create a thread safe generic logging API that did the same thing ...I saved a bunch of time and removed an external dependency by going with option 2 :)
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
The problem really isn't with the logger, but with the documentation (and I'm including article here on CodePRoject in that). For log4net (and for most other loggers, and most add-in libraries in general for that matter), there are: - things you do every time you want to log something. - things you do once for every class which logs something. - things you do once for each application which logs something. - things you do once in your lifetime. To understand how you use the logger, they should be explained in that order -- the thing you do the most taught first and with the most text. However, most go with a chronologic order -- exactly the reverse -- so you are bogged down with pages & pages of "configuration" documentation --- which in a real application will result one line of code.
Truth, James
-
I still use PhotoShop 7 (2002) -- it has never suddenly changed how it works. Nor has Office 2003.
Oh snap. :-D
Jeremy Falcon
-
Same old argument. If the existing wheels don't fit your needs you create the right wheels. A developer who doesn't do as much isn't worth a dime - baceause creating tools is precisely programmers' work.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Totally agree. Nothing wrong with using 3rd party code or frameworks but no one shoudl be afraid to roll up their sleeves and make it themselves if the need fits.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
I think its been mentioned before but this is ok if you have a single thread running. Any GUI based app with more than the main thread is going to be problematic. Loggin shouldn't be wasting time on the main thread running the program. You should wrap up a logging task, then fire it off onto another thread and forget about it. It can take ages (relatively) to open a file and append a log entry to it. And if you use locking (mutex) to make sure logging is thread safe, then all the threads wanting to log, end up waiting etc. Then there is the problem of multiple teams/modules writing to the log. It's nice to filter/partition log entries etc. Or use colour coding (then you need a log file reader !) So at home on my robotics projects (www.roboticsfordreamers.com) I use a simple - file open and writer - for simple projects (I always use small simple programs linked together with 0MQ anyway, so logging is always on a separate single thread !) I do agree though, that mostly this area is over-engineered, the people who look after these projects see them as in need of improving with additional functionality. What is nice, is when you have two approaches you can use in a software system. The super fast, lightweight, low functionality solution, and the complete bells and whistles solution. Maybe software (especially SDKs) should be developed in this way, then users can chose the trade off between functionality and speed.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated??? Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }static Logger() { if (string.IsNullOrEmpty(LogFile)) { var path = System.Reflection.Assembly.GetEntryAssembly().Location; LogFile = string.Format("{0}\\\\MyLogFile.txt", path); } } public static void Info(string message) { using (var sr = new StreamWriter(LogFile, true)) { sr.WriteLine(message); } }}
I've never understood why [This Much](https://csharp.today/log4net-tutorial-great-library-for-logging/) is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem. IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
I have a simple logging interface that I use: Shuttle.Core.Infrastructure/Shuttle.Core.Infrastructure/Logging at master · Shuttle/Shuttle.Core.Infrastructure · GitHub[^] I also have a Log4Net implementation: GitHub - Shuttle/Shuttle.Core.Log4Net: Log4Net ILog implementation.[^] I like Log4Net but with the logging abstracted away you can use anything from simple to advanced.
-
I still use PhotoShop 7 (2002) -- it has never suddenly changed how it works. Nor has Office 2003.
I recently came across instructions showing one how to legally download Photoshop CS2 along with it's key :) I don't currently need anything more advanced than that. The short version is to create an account on the Adobe site, search for CS2 and download with key...
-
I recently came across instructions showing one how to legally download Photoshop CS2 along with it's key :) I don't currently need anything more advanced than that. The short version is to create an account on the Adobe site, search for CS2 and download with key...
7 has always done what I need. Now that I'm getting back into photography I might look for something newer.
-
Same old argument. If the existing wheels don't fit your needs you create the right wheels. A developer who doesn't do as much isn't worth a dime - baceause creating tools is precisely programmers' work.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Meh. I'm getting paid for solving problems using software. Logging is a problem that's been solved numerous times already, and there's a multitude of amazing frameworks to choose from. Spend a few minutes reading (and understanding) the documentation, instead of wasting time trying to write another one from scratch. Not only will you end up with a better solution, it will be cheaper as well.