Serilog.Blazor.SqlServer
1.0.1
See the version list below for details.
dotnet add package Serilog.Blazor.SqlServer --version 1.0.1
NuGet\Install-Package Serilog.Blazor.SqlServer -Version 1.0.1
<PackageReference Include="Serilog.Blazor.SqlServer" Version="1.0.1" />
<PackageVersion Include="Serilog.Blazor.SqlServer" Version="1.0.1" />
<PackageReference Include="Serilog.Blazor.SqlServer" />
paket add Serilog.Blazor.SqlServer --version 1.0.1
#r "nuget: Serilog.Blazor.SqlServer, 1.0.1"
#:package Serilog.Blazor.SqlServer@1.0.1
#addin nuget:?package=Serilog.Blazor.SqlServer&version=1.0.1
#tool nuget:?package=Serilog.Blazor.SqlServer&version=1.0.1
Problem Statement
When self-hosting Serilog, there's no built-in log view experience. You have to query the serilog table manually and/or build your own UI or query feature. There are products like Seq and Graylog that provide a very polished log search and view exeperience, but have costs of their own. The reason for self-hosting to begin with is to avoid those costs. Furthermore, traditional homegrown log viewers have not provided the kind of insights and capabilities I'm looking for when examining logs. The goal for this project is to build the most capable log view experience I can, addressing longstanding pain points I've come across -- then offer it as a Razor Class Library NuGet package.
With .NET Aspire coming online recently, it has potential to disrupt and improve logging in ASP.NET Core due to its integrated open telemetry support and viewer dashboards. So, I'm very late to this party, and this project may be irrelevant in the short term. But I'm not convinced yet that Aspire's logging/otel does everything I want it to. Furthermore, many apps implement Serilog already, and I think there's a case for meeting apps where they are rather than pushing them to implement Aspire. (I want Aspire to succeed, and am happy to keep tabs on it as it evolves.)
Following is a list of logging pain points and how this project addresses them.
<details> <summary>Unexpected log levels</summary>
Over the years, I've had a hard time getting log levels and namespaces right -- that is, getting the desired level of logging at the right places in my code. Also, I didn't know until recently know there was a way to change levels at runtime without restarting my apps.
This project does these things:
- Offers the LogLevels abstract class.
- Implement this in your project to define your default logging levels by namespace prefix. Sample implementation is ApplicationLogLevels.
- Configure levels at runtime via the LevelToggle component
You can see which levels are in effect on which namespaces via the SourceContextFilter.
</details>
<details> <summary>Difficulties with correlation/deep tracing</summary> </details>
<details> <summary>Query limitations due to XML dependency in SQL Server sink</summary> </details>
<details> <summary>Logs getting too big</summary> </details>
<details> <summary>No built-in alerting</summary> </details>
<details> <summary>Stack traces are too hard to read</summary> </details>
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net9.0 is compatible. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 was computed. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net9.0
- Coravel (>= 6.0.2)
- Dapper (>= 2.1.66)
- Microsoft.Data.SqlClient (>= 5.2.2)
- Microsoft.EntityFrameworkCore (>= 9.0.4)
- Microsoft.EntityFrameworkCore.SqlServer (>= 9.0.4)
- Serilog.Blazor.Abstractions (>= 1.0.0)
- Serilog.Sinks.MSSqlServer (>= 8.2.0)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.