|
Wrap it all in one static call.
If logging is "intense" enough, feed a concurrent queue with a background worker to serialize it.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Have you seen Serilog[^]? It looks fairly simple to set up and use.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
pencil and paper. when an error happens, write it down. Simples. 
|
|
|
|
|
The old methods work best. I have heard that's how Google handles its internal search service logging. They have a team of 100 people with writing pads and pencils.
|
|
|
|
|
 I agree.
|
|
|
|
|
We currently use log4net... To log to a file.
Well, 10 files actually.
Of 10 MB max.
After which it overwrites the first again.
That sh*t is totally unreadable and for some reason we have to log EVERYTHING.
Yes, I DO believe some function was entered AND exited unless an error occurred, WHY THE HELL DO WE NEED TO LOG THAT!?
The worst part, our source code is littered with debug log statements and on all environments we have the minimum log level set to info, so the debug logs never even show.
Some people say "it's easy for debugging", but since when is a log file easier for debugging than a friggin' debugger!?
Then again, I recently figured out a bug in three minutes using nothing but an error message and a stack trace after a coworker angrily gave me the (my) code because "I didn't add log statements and now he had to spent 30 minutes figuring out what went wrong!"
It was a NullReference and by just looking at the code you could tell what parameters could be null, well at least I could 
Yes, logging is good, but only if they are exception logs (with stack trace!!!) or logging that is required for the business.
And rarely for debugging purposes, for example when multi-threading or handling input events (but in your console while debugging, not in a log file on production).
Funny enough I've had this discussion with multiple people who all disagree with me (and despite all that logging which I don't use I usually find bugs faster) 
|
|
|
|
|
Sander Rossel wrote: since when is a log file easier for debugging than a friggin' debugger!?
Since the moment your code hits production, and you cannot attach debugger to live system.
|
|
|
|
|
Personally, I've never needed to debug live systems.
Well, once... Because my logger failed! Really, the software worked as expected, except for the logging
All the other times an exception log sufficed to fix the problem 
|
|
|
|
|
Well, I agree that config is a bit of pain to sort out. But like with WCF you do it once then forget about it.
Kevin Marois wrote: what's wrong with this:
Quite a lot. Opening and closing a file every time you want to write a line isn't going to perform well. It may not be threadsafe, there's no mention of when the line was written or from which thread it happened. It always writes to a file, good for services but rubbish for a console app and if you've done it right your app will be both (enterprise solutions). It doesn't standardise on the format of each log line (important if you use a decent viewer). There's no concept of level - how do you distinguish a bit of helpful text from a critical error? How do you stop your file growing to GBs?
Each to their own...
Regards,
Rob Philpott.
|
|
|
|
|
I think he was just giving a very basic example to illustrate his point. Sheesh
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Sure that works, but please, change it to log to windows event log or syslog. No new build allowed.
|
|
|
|
|
|
|
This works better for me
LogFile = string.Format("{0}\\MyLogFile.txt", Path.GetDirectoryName(path));
|
|
|
|
|
Finally someone said what I felt. I ended up making my own way simpler logger than using the prebuilt ones. They were supposed to be easy, but no, you have to spend way too much time on learning their API and structure.
TVMU^P[[IGIOQHG^JSH A#@RFJ\c^JPL>;"[, /|+&WLEZGc
AFXc!L<br />
%^]*IRXD#@GKCQ R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_ADEPABIKRDFVS)EVLQK)JKQUFK[MUKs$GwU#QDXBER@CBN%
R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -----------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Nothing is wrong with that "at the most basic level", but when you're in a heavily multithreaded/concurrent/async/parallel environment with extreme demands for low latency and high throughput, you need a logging system that doesn't negatively affect the required functionality of the application, doesn't block anything, and doesn't garble data due to likely concurrent logging resource access.
As your basic example is written, it will surely "work" for most simple desktop user scenarios where the time it takes for the user to make a mouse click is 10 times higher than the time to complete a call to Logger::Info(), and nothing complicated is happening concurrently.
That said, it would *never* work in a game, in a VoIP app, in a high-grequency stock trading app.
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
You're doing something wrong. With NLog, all you need to do is include a nlog.config file in your project, and then to log you simply do the following:
static Logger _logger = LogManager.GetCurrentClassLogger();
_logger.Log(LogLevel.Info, "Your message");
"There are only 10 types of people in the world - those who know binary and those who don't."
|
|
|
|
|
Logging to a text file is obsolete. PaperTrailApp. 
I use this pretty much exclusively nowadays, writing to it over UDP is trivial:
byte[] buffer = Encoding.ASCII.GetBytes(message);
socket.SendTo(buffer, endPoint);
And it's been really helpful to be able to view logs from anywhere.
If it's at all interesting to you.
Marc
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I used Log4Net a while back but I thought at the time that it seemed to be overkill for what I wanted it to do. Glad I'm not the only one.
|
|
|
|
|
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
|
|
|
|
|
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 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.
|
|
|
|
|
My LogFile class is 160 lines of VB.Net code. I also have equivalents in VB6 and C++. This gives me a uniform LogFile class that supports automatic day rollover and log file names.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
