When transitively including both Microsoft.Extensions.Telemetry.Abstractions and Microsoft.Extensions.Logging.Abstractions, both logging source generators get installed only for .NET 6 and 7 targets

[mkane91301]

Description

At least when multi-targeting, if you include one package that transitively includes Microsoft.Extensions.Telemetry.Abstractions and another that transitively includes Microsoft.Extensions.Logging.Abstractions (for 8.0 RC2), both Microsoft.Extensions.Logging.Generators and Microsoft.Gen.Logging are installed for net6.0 and net7.0 targets (but not net462 or net8.0), resulting in two implementations of each partial logging method, causing CS0757 in the generated code and CS0121 where the logging method is called.

Reproduction Steps

Target .NET 6 or 7 (or both).

Install Microsoft.Extensions.Resilience (to transitively include Microsoft.Extensions.Telemetry.Abstractions) and Microsoft.Extensions.Caching.Memory (to transitively include Microsoft.Extensions.Logging.Abstractions).

Create a logging method using the LoggerMessage attribute.

Call the logging method.

Expected behavior

Only one implementation of the logging method is generated.

Actual behavior

Two implementations of the logging method are generated.

Regression?

Never tried this before.

Known Workarounds

Haven't found a workaround.

Configuration

This is happening building with the 8.0 RC2 SDK on Windows 11 (x64) in Preview 3 of VS 17.8.

Other information

No response

Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

At least when multi-targeting, if you include one package that transitively includes Microsoft.Extensions.Telemetry.Abstractions and another that transitively includes Microsoft.Extensions.Logging.Abstractions (for 8.0 RC2), both Microsoft.Extensions.Logging.Generators and Microsoft.Gen.Logging are installed for net6.0 and net7.0 targets (but not net462 or net8.0), resulting in two implementations of each partial logging method, causing CS0757 in the generated code and CS0121 where the logging method is called.

Reproduction Steps

Target .NET 6 or 7 (or both).

Install Microsoft.Extensions.Resilience (to transitively include Microsoft.Extensions.Telemetry.Abstractions) and Microsoft.Extensions.Caching.Memory (to transitively include Microsoft.Extensions.Logging.Abstractions).

Create a logging method using the LoggerMessage attribute.

Call the logging method.

Expected behavior

Only one implementation of the logging method is generated.

Actual behavior

Two implementations of the logging method are generated.

Regression?

Never tried this before.

Known Workarounds

Haven't found a workaround.

Configuration

This is happening building with the 8.0 RC2 SDK on Windows 11 (x64) in Preview 3 of VS 17.8.

Other information

No response

Author:	mkane91301
Assignees:	-
Labels:	area-Extensions-Logging
Milestone:	-

[tarekgh]

What is the package version did you use for Microsoft.Extensions.Telemetry.Abstractions? I think @joperezr already fixed that.

CC @joperezr @geeknoid

[mkane91301]

Today I installed the latest version of Microsoft.Extensions. Resiliency.Http, so it would be whatever version is included transitively with that. I’ve already put away my computer for the weekend so I can’t check right now (also I uninstalled it to get back to a buildable state before leaving for the weekend, as you probably understand).

[xakep139]

@dariusclay is this issue the same you observed recently?

[tarekgh]

I did a quick trial by creating a console app referencing the following packages:

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.0-rc.2.23479.6" />
    <PackageReference Include="Microsoft.Extensions.Telemetry.Abstractions" Version="8.0.0-rc.2.23510.2" />
  </ItemGroup>

And I used a simple LoggerMessage like the following:

public static partial class Log
{
    [LoggerMessage(EventId = 0, Level = LogLevel.Critical, Message = "Could not open socket to `{HostName}`")]
    public static partial void CouldNotOpenSocket(ILogger logger, string hostName);
}

I found the Microsoft.Extensions.Logging.Generators is successfully removed from the compilation as expected:

and here are the final analyzers that are participated in the build

But I see another build error:

D:\Temp\LogSourceGenRepro\Microsoft.Gen.Logging\Microsoft.Gen.Logging.LoggingGenerator\Logging.g.cs(13,21): error EXTEXP0003: 'Microsoft.Extensions.Logging.LoggerMessageHelper' is for evaluation purposes only and is subject to change or removal in future updates
. Suppress this diagnostic to proceed. (https://aka.ms/dotnet-extensions-warnings/EXTEXP0003) [D:\Temp\LogSourceGenRepro\LogSourceGenRepro.csproj]

The complaint is from the line var state = global::Microsoft.Extensions.Logging.LoggerMessageHelper.ThreadLocalState; in the generated code is:

// <auto-generated/>
#nullable enable
#pragma warning disable CS1591 // Compensate for https://github.com/dotnet/roslyn/issues/54103
partial class Log
{
    /// <summary>
    /// Logs "Could not open socket to `{HostName}`" at "Critical" level.
    /// </summary>
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Gen.Logging", "8.0.0.0")]
    public static partial void CouldNotOpenSocket(global::Microsoft.Extensions.Logging.ILogger logger, string hostName)
    {
        var state = global::Microsoft.Extensions.Logging.LoggerMessageHelper.ThreadLocalState;

        _ = state.ReserveTagSpace(2);
        state.TagArray[1] = new("HostName", hostName);
        state.TagArray[0] = new("{OriginalFormat}", "Could not open socket to `{HostName}`");

        logger.Log(
            global::Microsoft.Extensions.Logging.LogLevel.Critical,
            new(0, nameof(CouldNotOpenSocket)),
            state,
            null,
            static (s, _) =>
            {
                var HostName = s.TagArray[1].Value ?? "(null)";
                return global::System.FormattableString.Invariant($"Could not open socket to `{HostName}`");
            });

        state.Clear();
    }
}

@geeknoid may be good if you can have a quick look.

[mkane91301]

This trial includes them directly, not transitively. I only saw this behavior when both were included transitively and only for net6.0 and net7.0 targets when multitargeting (but I never tried without multitargeting).

[dariusclay]

Yes, I'm also experiencing something similar, thanks @xakep139

In my setup I'm multi-targeting net462, net6.0 and net7.0, using the same versions as the test @tarekgh has.

When I take out Microsoft.Extensions.Telemetry.Abstractions package, the logging source generator works as intended. This is on VS 17.7.5.

[xakep139]

@tarekgh, the [Experimental] attribute is reported as an error as described in dotnet/csharplang#7597 and it can be suppressed with #pragma warning disable EXTEXP0003 in that case. The generated code can't be modified though, but the [Experimental] attribute was removed from LoggerMessageHelper. Thus, it shouldn't emit the diagnostic in 8.0 release.

[joperezr]

Can someone that has a repro (@mkane91301 or @dariusclay) attach a repro project so that we can take a look and investigate? It may have to do with the fact that we use build\ folder inside the package as opposed to buildTransitive\, but in order to validate it I want to have a repro project to test the fix.

[joperezr]

@tarekgh, the [Experimental] attribute is reported as an error as described in dotnet/csharplang#7597 and it can be suppressed with #pragma warning disable EXTEXP0003 in that case. The generated code can't be modified though, but the [Experimental] attribute was removed from LoggerMessageHelper. Thus, it shouldn't emit the diagnostic in 8.0 release.

Yeah, we should do a spot check in dotnet/extensions packages because by default we want no warnings to be emitted inside generated code. Those should all have #pragma to make sure they don't throw a warning, since as you said, this can't be fixed unless we use NoWarn and that shouldn't be the case. Instead we should just make sure that the gesture that triggers the generator (the attribute in this case) would throw the warning.