Ksh.Logger
2024.2.1
See the version list below for details.
dotnet add package Ksh.Logger --version 2024.2.1
NuGet\Install-Package Ksh.Logger -Version 2024.2.1
<PackageReference Include="Ksh.Logger" Version="2024.2.1" />
paket add Ksh.Logger --version 2024.2.1
#r "nuget: Ksh.Logger, 2024.2.1"
// Install Ksh.Logger as a Cake Addin #addin nuget:?package=Ksh.Logger&version=2024.2.1 // Install Ksh.Logger as a Cake Tool #tool nuget:?package=Ksh.Logger&version=2024.2.1
Ksh.Logger
package | version | downloads |
---|---|---|
Ksh.Logger | ||
Ksh.Logger.Abstractions |
The world's most flexible and light-weight logger!
Main contents
Usage
LoggerFactory
var logger = new StandardLoggerFactory()
.AddConsoleLogger()
.AddFileLogger("path.to.log")
.CreateLogger();
logger.Info("hello world");
ServiceCollection
Please make sure, the package is installed already.
dotnet add package Microsoft.Extensions.DependencyInjection
You can then set up the logger and register the module. The logger can be added to any class you want after that.
var services = new ServiceCollection();
services.AddKshLogger();
services.AddSingleton<ILogger>(
srv => srv.GetService<ILoggerFactory>()!
.AddConsoleLogger()
.AddFileLogger("path.to.log")
.CreateLogger()
);
// just for demo, you don't need this in production
var kernel = services.BuildServiceProvider();
var logger = kernel.GetService<ILogger>()!;
logger.Info("hello world");
You can now log in to a file or console. You can get rid of the console and file propagator if you want to.
Customization
This logger, as mentioned, is extremely adaptable. If you're using a logging framework, you can let it handle the stuff like formatting or so. After a while, you can switch to using only one logger.
There's a layer of abstraction that can be used independently or in UnitTests. That abstraction layer will make you future-proof.
ILogMessagePropagator
This Logger's superpowers are propagators. You can notify anything you want. Simply use the ILogMessagePropagator
Interface and do whatever you want with the message.
Every log message will utilize this method.
This example shows how to know if your service has stopped working and send an email when it happens.
public class CustomPropagator(IEmailClient emailClient) : ILogMessagePropagator
{
public void Propagate(LogMessage message)
{
if (message.Severity == LogSeverity.Fatal)
{
emailClient.SendEmail(message.Message);
}
}
}
You can put this propagator directly into the logger or into the factory.
loggerFactory.AddPropagator(new CustomPropagator(emailClient));
ILogMessageFormatter
Let's talk about the formatters. These sneaky guys are extremely helpful by changing the appearance of the message.
I think it is an edge case to use something different from what was implemented. But you can format any message depending on your needs.
All built-in propagators are using the formatter. Custom propagators are not, but I highly recommend using them as well. Just for consistency purposes.
public class MyCustomLogMessageFormatter : ILogMessageFormatter
{
public string Format(LogMessage message)
=> message.Exception == null
? $"{message.Severity} {message.TimeOfDay:s} {message.Message}"
: $"{message.Severity} {message.TimeOfDay:s} {message.Message}{Environment.NewLine}{message.Exception}";
}
LogSeverity
We have 6 different severities: Trace
, Debug
, Info
, Warn
, Error
and Fatal
.
Of course, you can use these classifications as you like! From my experience, I would like to provide you with a recommendation. Maybe it is helpful. 😃
severity | recommendation |
---|---|
Trace |
You don't need it most of the time. It can be used if you want to log which method is currently being called. 👀 |
Debug |
I like to put some additional and noisy stuff into here. This is a good Log Level to save the state of the variables. 🔈 |
Info |
Any regular log message 💬 |
Warn |
Something strange is happening, but I (the app) can manage it 😨 |
Error |
Something strange is happening, but the user can manage it 🆘 |
Fatal |
Okay, I am dead 💀 |
Filter and Verbosity
Okay, real-talk. Who the heck is reading log files? Really, no one. They're only useful when you're looking into some issues. One full log file and some only for warnings, errors and so on are what I like to have.
var logger = new StandardLoggerFactory()
// will log debug and above
.AddConsoleLogger(new() {
Verbosity = LogSeverity.Debug
})
// by default everything will be logged!
.AddFileLogger("noisy.log")
// will log only infos
.AddFileLogger(new() {
OutputFile = "info.log",
Filter = LogSeverity.Info
})
// will track only warnings
.AddFileLogger("warnings.log", filter: LogSeverity.Warn)
// will tracks errors and fatals
.AddFileLogger("errors.log", verbosity: LogSeverity.Error)
// use some custom propagator
.CreateLogger();
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
-
net8.0
- Ksh.Logger.Abstractions (>= 2024.2.1)
- Microsoft.Extensions.DependencyInjection.Abstractions (>= 8.0.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
2024.2.2-rc.1 | 28 | 5/2/2024 |
2024.2.1 | 81 | 5/2/2024 |
2024.1.3 | 126 | 3/23/2024 |
2024.1.3-rc.4 | 60 | 3/18/2024 |
2024.1.3-rc.3 | 56 | 3/18/2024 |
2024.1.2 | 118 | 3/18/2024 |
2024.1.2-rc.2 | 54 | 3/18/2024 |
2024.1.1 | 126 | 3/18/2024 |