.Net Logging
-
I disagree. When you have code running in production it;s usually more difficult to diagnose what's happening, so logging gives you an advantage.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Me thinks you misunderstood. By "the framework" he's referencing "the Logging framework", not logging in general.
#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
-
pencil and paper. when an error happens, write it down. Simples. :-D
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. :-D
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
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.
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 shit 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) :confused:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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.
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.
-
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. :-D
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
:thumbsup: 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 shit 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) :confused:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
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.
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
-
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
-
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.
That's why I wrote Mini Drop-in Replacement for log4net[^]
-
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 wrote my own logger for that reason (and because it is fun to write stuff). If it is useful for you, you can check it out here: GitHub - sizingservers/sizingservers.log: An application logger for any 64 bit .Net 4.5 (and up) Windows desktop (maybe other app types) app.[^] Cheers
-
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.
This works better for me
LogFile = string.Format("{0}\\MyLogFile.txt", Path.GetDirectoryName(path));
-
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.
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
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 :)
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
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.
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 %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKQUFK[M`UKs*$GwU#QDXBER@CBN% R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
----------------------------------------------- 128 bit encrypted signature, crack if you can
-
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.
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
-
Logging frameworks (etc.) are for developers who are too stupid to figure it out for themselves. If you're smart enough to recognize that the framework is crap, you don't need that framework. :cool:
Are you seriously suggesting re-inventing the wheel?
"There are only 10 types of people in the world - those who know binary and those who don't."
-
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.
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."
-
Are you seriously suggesting re-inventing the wheel?
"There are only 10 types of people in the world - those who know binary and those who don't."
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"
-
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.
Logging to a text file is obsolete. [PaperTrailApp](https://papertrailapp.com/). ;) 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
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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.
