|
|
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
|
|
|
|
|
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"
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
For a simple application, what you posted may suffice. For complex, multi threaded services, the logging needs to be thread-safe, needs to be performant (even async), and may need to support multiple log listeners - and the target may be a text file, a database, azure storage, a web API, etc.
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.
|
|
|
|
|
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 don't have it yet but the personal use subscription is quite affordable. 10 bucks a month gives you Photoshop and a couple other tools I think. You never really own it though - just a lease.
|
|
|
|
|
Yeah totally, and they allow you to use it on more than one computer, so it's not too shabby. But when you start using the new version (CC 2017) it just starts to seem like the new crap is just too much and is distracting. And I've always used Photoshop as an example of a simple, clean yet powerful UI design. Not so much now.
Jeremy Falcon
|
|
|
|
|
I still use PhotoShop 7 (2002) -- it has never suddenly changed how it works. Nor has Office 2003.
|
|
|
|
|
Oh snap.
Jeremy Falcon
|
|
|
|
|
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.
|
|
|
|
|
X = What features you need from your logging system
Y = What features a logging framework provides
Usefulness of logging system = 1 / (Y - X)
|
|
|
|
|
Clearly some stuff is over-engineered. If what you've posted meets your requirements, then by all means--you shouldn't ever feel obligated to use any of the bloated alternatives that exist.
|
|
|
|
|
Kevin Marois wrote: 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);
}
}
Well, it won't work in production for starters!
The Executing assembly in production is normally in a folder that "hangs off" "Program Files" or "Program Files (x86)", and folders in that path are normally write protected for antivirus reasons.
Use a "publically writable" folder like one below Application.CommonAppDataPath or Environment.SpecialFolder.CommonApplicationData :
public static Guid AppGuid
{
get
{
Assembly asm = Assembly.GetEntryAssembly();
object[] attr = (asm.GetCustomAttributes(typeof(GuidAttribute), true));
return new Guid((attr[0] as GuidAttribute).Value);
}
}
public static Guid AssemblyGuid
{
get
{
Assembly asm = Assembly.GetExecutingAssembly();
object[] attr = (asm.GetCustomAttributes(typeof(GuidAttribute), true));
return new Guid((attr[0] as GuidAttribute).Value);
}
}
public static string AllUsersDataFolder
{
get
{
Guid appGuid = AppGuid;
string folderBase = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
string dir = string.Format(@"{0}\{1}\", folderBase, appGuid.ToString("B").ToUpper());
return CheckDir(dir);
}
}
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
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.
|
|
|
|
|
Above was mentioned thread safe,
another gotya is running multiple instances of the same prog.
BTW:
Kevin Marois wrote: 've never understood why This Much is needed just to write to a silly log file
If the log file is silly, why log anything.
Sin tack ear lol
Pressing the any key may be continuate
|
|
|
|
|
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.
|
|
|
|