Serilog.Extensions.Logging 10.0.0 not compatible with .NET versions less than 10

[BentTranberg]

If I try to update Serilog.Extensions.Logging from 9.0.2 to 10.0.0, I get a compile error.

Detected package downgrade: Microsoft.Extensions.Logging from 10.0.0 to centrally defined 9.0.10. Update the centrally managed package version to a higher version. 
 TdDesktop -> Serilog.Extensions.Logging 10.0.0 -> Microsoft.Extensions.Logging (>= 10.0.0) 
 TdDesktop -> Microsoft.Extensions.Logging (>= 9.0.10)

My projects are all on .NET 9. The thing is, I don't expect I can update to .NET 10 for several months, due to many issues in VS and SDK and System and Microsoft libraries of version 10.

In the meantime, this particular library can't be updated to the latest version. That's a pretty unusual requirement for a well maintained library on NuGet.

So I question whether there's a sufficiently good reason Serilog.Extensions.Logging version 10.0.0 must have a dependency to Microsoft.Extensions.Logging >= v 10.0.0 for all these .NET versions, listed in the Package Details of the NuGet package manager in VS : .net 8.0, .net9.0, .net10.0

[nblumhardt]

Thanks for the note. This is mentioned in the README, but not very prominently, so I've just updated the note there to match the one in Serilog.Extensions.Hosting:

Versioning: This package tracks the versioning and target framework support of its Microsoft.Extensions.Logging dependency. Most users should > choose the version of _Serilog.Extensions.Logging that matches their application's target framework. I.e. if you're targeting .NET 7.x, choose a 7.x version of Serilog.Extensions.Logging. If you're targeting .NET 8.x, choose an 8.x Serilog.Extensions.Logging version, and so on.

This scheme effectively means that the 9.x versions of this package are the latest builds for .NET 9. Feature coverage is practically identical, so sticking with the v9 package until you update everything is the way to go.

Early versions of these Serilog libraries did use the scheme you're suggesting, but we found this exploded out the support matrix (e.g. a v9 Serilog extension could end up with a v10 Microsoft extension deployed alongside it on .NET 8), and some of these combinations broke, causing headaches for people stuck in particular scenarios.

Tying the Serilog extensions versions to the Microsoft extensions versions means it's easy to pick reliable/known-good combinations, and apart from the gotcha when bulk-upgrading packages, it's been much better to support in terms of runtime outcomes.

HTH!