Bump Microsoft.Extensions.Logging to net8

[reyang]

Related to #3205.

This is essentially the same thing as #4550.

[codecov]

Codecov Report

Merging #4920 (842ca30) into main (d76542e) will decrease coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #4920      +/-   ##
==========================================
- Coverage   83.44%   83.29%   -0.16%     
==========================================
  Files         295      295              
  Lines       12324    12324              
==========================================
- Hits        10284    10265      -19     
- Misses       2040     2059      +19     

Flag	Coverage Δ
unittests	83.29% <ø> (-0.16%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 7 files with indirect coverage changes

[Kielek]

@reyang, this kind of PRs are killing possibility of using Automatic Instrumentation without including it in build pipeline on .NET. .NET Framework is still pretty safe (after we make a release with stable reference to the newly released library version).

2) Each minor version bump is normally security hotfixes or critical bug fixes.

Based on https://www.nuget.org/packages/Microsoft.Extensions.Logging/#versions-body-tab there is no security issue in any 3.1.x release. The same is for 6.0.0 and 7.0.0.
So we have only critical bug fixes from 3.1.x.

As I remember the package is part of the .NET 6+ and even if your application is referencing 3.1.0 it will be implicitly bumped to the version included in .NET.

Based on this, it should be safe to update dependency to 6.0.0 (I assume that it includes all critical fixes).

IMO EventId auto-generation is not good enough reason to update now, We can consider doing it when .NET6 reach EOL: November 12, 2024. It can be potentially done for release synced with .NET9.

FYI: @open-telemetry/dotnet-instrumentation-maintainers

[noahfalk]

I wasn't sure how some of the nullability and Http reference changes related to M.E.Logging, but no qualms with them.

[reyang]

@reyang, this kind of PRs are killing possibility of using Automatic Instrumentation without including it in build pipeline on .NET. .NET Framework is still pretty safe (after we make a release with stable reference to the newly released library version).

@Kielek would you provide some context here? For example, we're already doing the same thing for System.Diagnostics.DiagnosticSource

opentelemetry-dotnet/Directory.Packages.props

Lines 33 to 42 in dc1f09d

	<!--
	Typically, the latest stable version of System.Diagnostics.DiagnosticSource should be used here because:
	1) Each major version bump will have some new OpenTelemetry API capabilities (e.g. .NET 6 introduced Meter
	API, .NET 7 added UpDownCounter, .NET 8 is adding Meter/Instrument level attributes support, .NET 9 might
	add Advice/Hint API) that the OpenTelemetry components rely on.
	2) Each minor version bump is normally security hotfixes or critical bug fixes.
	3) The .NET runtime team provides extra backward compatibility guarantee to System.Diagnostics.DiagnosticSource
	even during major version bumps, so compatibility is not a concern here.
	-->
	<PackageVersion Include="System.Diagnostics.DiagnosticSource" Version="7.0.2" />

How does auto-instrumention solve the System.Diagnostics.DiagnosticSource version challenge today, can the same approach be applied to Microsoft.Extensions.Logging? Is there something that folks from .NET runtime can help?

[cijothomas]

Fixes #3205.

This is essentially the same thing as #4550.

The PR description can be updated to exclude Fixes #3205, as even with this PR, SDK won't require Ms.Ext.Logging 8, so #3205 is still open.