v3.1.0
- #1935 - remove
CHANGES.md(@sungam3r) - #1936, #1922 -
README.mdupdates (@nblumhardt) - #1942 - remove redundant
GetTypeInfo()calls (@SimonCropp) - #1947 - message template caching performance improvements (@epeshk)
- #1948 - reduce allocations in
Logger.Write()(@epeshk) - #1955 breaking - collect and propagate
Activity.Current.TraceIdandSpanIdautomatically inLogger.Write()(@nblumhardt) - #1964 - don't cache reusable string writers with large buffer sizes (@Jakimar)
- #1969 -
README.mdupdates (@bartelink) - #1971 - drop test coverage for unsupported .NET Core versions (@bartelink)
Built-in trace and span id support
This release adds two new first-class properties to LogEvent: TraceId and SpanId. These are set automatically in Logger.Write() to the corresponding property values from System.Diagnostics.Activity.Current.
The major benefit of this change is that sinks, once updated, can reliably propagate trace and span ids through to back-ends that support them (in much the same way that first-class timestamps, messages, levels, and exceptions are used today).
The sinks maintained under serilog/serilog, along with formatting helpers such as Serilog.Formatting.Compact and Serilog.Expressions, are already compatible with this change or have pending releases that add compatibility.
Dropped .NET Core 2.1 and 3.0 support
On .NET Core 2.1 and 3.0, projects targeting Serilog 3.1+ will fail to build, with:
/project/packages/system.runtime.compilerservices.unsafe/6.0.0/buildTransitive/netcoreapp2.0
/System.Runtime.CompilerServices.Unsafe.targets(4,5): error : System.Runtime.CompilerServices.Unsafe
doesn't support netcoreapp2.1. Consider updating your TargetFramework to netcoreapp3.1 or later.
Affected consumers should continue to use Serilog 3.0 or earlier. See #1983 for a discussion of this issue.
Technical breaking change
Trace and span id collection includes support for {TraceId} and {SpanId} placeholders in output templates (commonly used when formatting text log files). Where previously these names resolved to user-defined properties, they now resolve to the built-in LogEvent.TraceId and LogEvent.SpanId values, respectively.
Impact is expected to be low/zero, because the trace and span id values in any user-added properties are almost certainly identical to the built-in ones.
