You are doing logging in .NET wrong. Let’s fix it.
summary
Claims concrete fixes for .NET logging: treat the log text as a message template not a computed string, stop using string interpolation/concatenation to avoid per-entry string and boxing allocations, adopt structured logging so parameters like paymentId become queryable fields, use Serilog or the built-in ILogger Source Generator or Serilog overloads to avoid unnecessary boxing, set default level to warning, and be laconic. Implementing these cuts log churn, lowers bills (one case reports a 99% logging cost reduction) and preserves debuggability.
AI-written summary · about
chapters (23)
- 0:00Logging in .NET
- 1:49Talk title concerns
- 3:13Myth: no logging needed
- 6:24What this talk is really about
- 7:28Rule 1: Message template
- 8:35Logging mistakes
- 12:12String interpolation internals
- 14:03Stack vs Heap memory
- 19:18Boxing impact on logging
- 23:15C# 10 interpolation handlers
- 26:04Logging performance cost
- 27:06Rule 2: No string interpolation
- 29:14Structured logging intro
- 31:00Rule 3: Structured logging
- 33:31Serilog structured logging
- 36:02Log levels impact
- 39:48Rule 4: Avoid boxing
- 40:10Source generators for logging
- 43:43Rule 6: Avoid over-engineering
- 46:51Rule 7: Default log level
- 50:42Logging performance vs responsibility
- 51:27Why we log
- 52:29Rule 8: Log only necessary
related talks
49mYou are doing logging in .NET wrong. Let’s fix it
54mLogging, Metrics and Events in ASP NET Core
57mDon’t need to understand the details of .NET. Until you do
53mLogging Is Hot Again
54mSerilog: Instrumentation that Works for You
29mApplication Logging
53m.NET:Stay calm and Serilog + Elastic Search + Kibana on .NET Core
05mWhy You Should Add Logging To Your Code (and make it more helpful)