LoggerMessage generator causes compile error with WPF app that uses AspNetCore framework

[AE-ajones]

Describe the bug

Using generated logging methods using LoggerMessageAttribute causes compile errors in WPF projects if the AspNetCore framework is used

To Reproduce

I believe this was introduced between MSBuild 17.13 and 17.14.16. Minimal repro at https://gist.github.com/AE-ajones/beab8fd26e1a5e7699805376520747eb
Commenting out the FrameworkReference line in the csproj or deleting MainWindow.xaml removes the error.

Exceptions (if any)

Compile errors -

0>LoggerMessage.g.cs(11,33): Error CS0102 : The type 'App' already contains a definition for '__LogMethodErrorStruct'
0>LoggerMessage.g.cs(59,37): Error CS0757 : A partial method may not have multiple implementing declarations
0>LoggerMessage.g.cs(9,10): Error CS0579 : Duplicate 'global::System.CodeDom.Compiler.GeneratedCodeAttribute' attribute
0>LoggerMessage.g.cs(10,10): Error CS0579 : Duplicate 'global::System.ComponentModel.EditorBrowsableAttribute' attribute
0>LoggerMessage.g.cs(11,33): Error CS8646 : 'IEnumerable.GetEnumerator()' is explicitly implemented more than once.
0>LoggerMessage.g.cs(35,85): Error CS0111 : Type 'App.__LogMethodErrorStruct' already defines a member called 'this' with the same parameter types
0>LoggerMessage.g.cs(16,20): Error CS0111 : Type 'App.__LogMethodErrorStruct' already defines a member called '__LogMethodErrorStruct' with the same parameter types
0>LoggerMessage.g.cs(23,36): Error CS0111 : Type 'App.__LogMethodErrorStruct' already defines a member called 'ToString' with the same parameter types
0>LoggerMessage.g.cs(47,133): Error CS0111 : Type 'App.__LogMethodErrorStruct' already defines a member called 'GetEnumerator' with the same parameter types
0>LoggerMessage.g.cs(55,91): Error CS0111 : Type 'App.__LogMethodErrorStruct' already defines a member called 'global::System.Collections.IEnumerable.GetEnumerator' with the same parameter types

Further technical details

details of dotnet --info

.NET SDK: Version: 9.0.304 Commit: f12f5f689e Workload version: 9.0.300-manifests.c71eb59d MSBuild version: 17.14.16+5d8159c5f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.304\

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.8
Architecture: x64
Commit: aae90fa090

.NET SDKs installed:
6.0.428 [C:\Program Files\dotnet\sdk]
7.0.410 [C:\Program Files\dotnet\sdk]
8.0.204 [C:\Program Files\dotnet\sdk]
9.0.109 [C:\Program Files\dotnet\sdk]
9.0.204 [C:\Program Files\dotnet\sdk]
9.0.304 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Fails in VS, Rider and dotnet build

[AE-ajones]

It looks like ANY source generator will fail - I just tried to add JSON serializer generation to the same project and it fails in the same manner. IMO this bumps the priority up significantly.

[tannergooding]

CC. @baronfel

This looks like we're getting two copies of the Microsoft.Extensions.Logging.Generator included. One via the FrameworkReference to Microsoft.AspNetCore.App and one via the PackageReference to Microsoft.Extensions.Logging.Abstractions

Which repo does the props/targets/dependencies for Microsoft.AspNetCore.App live in, as that'd be the likely place to triage this

-- Noting I didn't do any actually digging into this yet, was responding to a question on the C# community discord on if this got logged to the right location.

[baronfel]

@tannergooding I believe the ASPNET shared framework is owned by dotnet/aspnetcore and is authored here. Maybe @wtgodbe can help triage/redirect?

[wtgodbe]

We do include Logging.Abstractions in the aspnetcore SharedFx, and have for some time. I'm not sure what would have changed in MSBuild to have this start causing issues now. I know dotnet/extensions had a similar issue w/ Logging.Generators that was fixed by dotnet/extensions#4287 - maybe something similar is needed here? CC @joperezr

[ericstj]

I suspect this is caused by this bug dotnet/sdk#36122

[AE-ajones]

I suspect this is caused by this bug #36122

Based on that discussion I tried adding the following to the csproj - the build error is still present.

        <EnableRequestDelegateGenerator>false</EnableRequestDelegateGenerator>
        <EnableConfigurationBindingGenerator>false</EnableConfigurationBindingGenerator>

I also tried importing Microsoft.NET.Sdk.Web.ProjectSystem.targets with the same results. Perhaps I'm misunderstanding the workaround

[ericstj]

I might have spoken too soon - I saw the repro was similar to that case (framework reference without SDK) but that wouldn't explain JSON breaking too. I'll take a closer look. It could be that conflict resolution broke here - it's supposed to deduplicate the generator that comes from the framework and nuget package.

This repro won't be using NuGet package pruning to remove the extra generator since this targets 9.0. (also repro is on 9.0 SDK)

[AE-ajones]

Perhaps I spoke too soon - making use of Json serialization source generation caused a similar issue in my actual project but it doesn't seem to break the sample project. I'll track down the cause of that separately and reply back with more information.

[ericstj]

JSON doesn't break because there's not a duplicate source generator as the package isn't referenced. It does break if you reference the STJ package though.

I think this is actually a duplicate of #9589. WPF's nested build does not run conflict resolution on analyzers but it does raise all the NuGet package analyzers. Let me add a workaround to that, and more discussion.

[MackinnonBuck]

@ericstj, should we close this out as a dupe of #9589?