dotnet / dotnet/NuGet.BuildTasks
Support multi-targeting for Roslyn components
- Dominant language
- PowerShell
- Stars
- 47
- Forks
- 65
- PR merge metrics
- No merged PRs in 30d
Description
Opening an issue here to add support for https://github.com/dotnet/sdk/issues/20355 in the [ResolveNuGetPackageAssets Task](https://github.com/NuGet/NuGet.BuildTasks/blob/1d8af3499f94a32c1d128a42faceade39c1f4337/src/Microsoft.NuGet.Build.Tasks/ResolveNuGetPackageAssets.cs#L444-L470). We need to update the NuGet MSBuild logic with support for multi-targeted Roslyn components. That way developers using non-SDK .NET projects will get the same Analyzers selected as SDK projects.
Any non-SDK style projects that are referencing NuGet packages with multi-targeted Source Generators (ex. System.Text.Json and Microsoft.Extensions.Logging.Abstractions) are not getting the best possible Source Generator loaded. This results in slower builds and IDE interactions because the source generators targeting older Roslyn versions don't have the latest incremental logic in them. They need newer Roslyn versions to fix the performance bugs.
Those NuGet packages have fallback logic when `SupportsRoslynComponentVersioning` is not true to just pick the oldest supported version. This allows the NuGet package to work with older tools that don't support multi-targeting Roslyn. But when `SupportsRoslynComponentVersioning` is set to true, the tooling that picks the `analyzer` assets from the NuGet package will pick the correct Source Generator/Analyzer based on the Roslyn version targeted and the current `$(CompilerApiVersion)`.
We should re-implement the logic that is used in SDK-style projects (https://github.com/dotnet/sdk/pull/20793) in the ResolveNuGetPackageAssets Task.
See also https://github.com/dotnet/roslyn/issues/63522#issuecomment-1232139382
cc @ericstj
Contributor guide
Assessment
This issue has not been assessed yet.