Open bachratyg opened 1 year ago
At its core, this stems from having two different versions of the source generator (a type of analyzer) run during a build.
This error happens in CoreCompile
as depended upon by _CompileTemporaryAssembly
, which is executed in a new subbuild by GenerateTemporaryTargetAssembly
.
This task does not use ResolveAssemblies
(which avoids duplicates via _HandlePackageFileConflicts
). Instead it does a more limited resolution of package assemblies.
What is specifically happening here is that GenerateTemporaryTargetAssembly is passed the complete list of analyzers that the main compilation used. It pre-adds those as <Analyzer>
items. It then resolves packages, which potentially adds some analyzers again. Finally, it attempts to deduplicate these with a RemoveDuplicateAnalyzers
target, which was added in PR #6799.
That works fine for deduplicating a source generator that only lives in a nuget package, but does not work for deduping a source generator between an in-box version and one from a nuget package.
As a temporary workaround, users can add thr following to their csproj (adjust to be correct culture for main XAML files):
<UICulture>en-US</UICulture>
and also add this attribute (with the same value as UICulture property):
[assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.Satellite)]
This avoids the using GenerateTemporaryTargetAssembly
at the cost of creating a satellite assembly to house the default version of the compiled markup, instead of embedding it into the main assembly.
Have GenerateTemporaryTargetAssembly add the analyzers it is passed as new <PreresolvedAnalyzer>
item type, either instead or in addition to passing them as <Analyzer>
items.
Then instead of RemoveDuplicateAnalyzers
, we can do:
<Target Name="UsePreresolvedAnalyzers" Condition="'@(PreresolvedAnalyzer)' != ''" BeforeTargets="CoreCompile">
<ItemGroup>
<Analyzer Remove="@(Analyzer)" />
<Analyzer Include="@(PreresolvedAnalyzer)" />
</ItemGroup>
</Target>
The result of this is that we end up using the exact same set of source generators as regular build, which seems to be the intention, given that the code was already adding them as <Analyzer>
items in the first place.
I have same issue in .NET SDK 8.0.301. Only temporary workaround works for me. Thanks anyway.
Description
Referencing certain NuGets in a Wpf project and using STJ source generation the build breaks.
Reproduction Steps
Microsoft.Extensions.Hosting
or anything that indirectly depends onSystem.Text.Json
[JsonSerializable(typeof(string[]))] public partial class JsonInfo : JsonSerializerContext { }
MSBuild version 17.5.0+6f08c67f3 for .NET Determining projects to restore... Restored\WpfApp1.csproj (in 352 ms).
dotnet --info
``` .NET SDK: Version: 7.0.202 Commit: 6c74320bc3 Runtime Environment: OS Name: Windows OS Version: 10.0.19045 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.202\ Host: Version: 7.0.4 Architecture: x64 Commit: 0a396acafe .NET SDKs installed: 7.0.202 [C:\Program Files\dotnet\sdk] .NET runtimes installed: Microsoft.AspNetCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Other architectures found: arm64 [C:\Program Files\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation] 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 ```