We initially didn't use any logging or debug tracing but after spending few weeks to trace down some data corruption we decided to put required Debug.Write and Trace for production and Debug.Assert
So now question is What is the best practice to use debug and trace logging. I am just looking for some thing generic.
public void AddRectodatabase(object record)
{
Debug.WriteLine(record.ToString());
Trace.WriteLine(record.ToString());
// Add it to databse
Debug.Assert(true, "Use this on case by case basis");
}
Is this good enough for general purpose, am i doing anything wrong in there?
We want to stick with .net System.Diagnostics over other alternatives like log4net.
Is there any thing else useful in System.Diagnostics?
You should plan on raising ETW trace events throughout your app - not only to alert listeners to issues, but also to provide visibility into the behavior and even performance of your apps' and components' performance.
ETW is an (insanely) high performance and (astonishingly) low-impact way of raising events that can be gathered and analyzed - even in production environments. It's the logging & tracing infrastructure used throughout Windows, SQL, etc.
Three useful links for you:
Read all 3 in order and then re-read - later information will be highly useful, but will be harder to understand unless you grasp the basics first ;) Ignore the instructions to use logman to start and stop your trace collections; use XPerf instead.
If you've not yet seen the Perf toolkit and XPerf viewer, then you're in for a treat! :D
I strongly encourage you to consider raising start & stop events at the start and end of all of your apps' most important features so that you can overlay these events with other telemetry so that you can see, for example, the impact of your apps features on Disk, network, memory, CPU, etc.
Hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With