Resolve analyzers from the analyzers group in project.assets.json

[martinrrm]

Summary

This is the SDK (build) half of the "indicate analyzer assets in project.assets.json" feature (spec: NuGet/Home#14455). It teaches ResolvePackageAssets to consume the new analyzers group that NuGet restore writes into project.assets.json, instead of scanning every file under analyzers/ in each package.

What changes

When restore has recorded RestoreEnableAnalyzerAssets in the assets file (opt-in, gated to .NET 11+ on the restore side), ResolvePackageAssets now:

• Reads analyzers from the analyzers group in each package's target rather than scanning library.Files. The group already has PrivateAssets / ExcludeAssets / IncludeAssets applied by restore.
• Selects by metadata instead of parsing paths:
  • codeLanguage must match the project language, or be language-agnostic (any);
  • among compiler-version-specific analyzers the highest applicable compilerApiVersion wins; if the project's compiler version is unknown, every variant is treated as version-agnostic.
• Honors the restore decision, not the raw MSBuild property. The decision reads RestoreMetadata.RestoreEnableAnalyzerAssets persisted in the assets file, because the .NET 11 TFM gate lives in NuGet's targets (not imported at build). When the feature is enabled but a package has no analyzers group, the SDK does not fall back to legacy scanning.
• Preserves legacy behavior when the feature is off (the default): the existing path-based AnalyzerResolver scanning is used unchanged.
• Emits Low-importance diagnostics for each analyzer included/excluded and why, visible at -v detailed, matching the selection-tracing style used elsewhere in these tasks.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the SDK’s ResolvePackageAssets task to resolve analyzers using the new analyzers group in project.assets.json (when restore has opted in via persisted restore metadata), avoiding legacy package-file scanning and applying analyzer selection based on language and compiler API version metadata.

Changes:

• Switched analyzer resolution to prefer lock-file analyzers group assets when RestoreEnableAnalyzerAssets is persisted by restore; otherwise preserved legacy scanning.
• Added/expanded unit tests for language + compiler-version analyzer selection semantics and multi-targeting behavior.
• Extended dotnet build integration coverage to validate both legacy and new analyzer-resolution modes.

Show a summary per file

File	Description
test/Microsoft.NET.Build.Tasks.Tests/GivenAResolvePackageAssetsTask.cs	Adds unit tests covering analyzer-group selection (language, compiler version, placeholders, multi-targeting) and feature-flag behaviors.
test/dotnet.Tests/CommandTests/Build/GivenDotnetBuildBuildsCsproj.cs	Extends integration test matrix to run with analyzer-assets enabled/disabled and validates restore emitted expected assets-file shape.
src/Tasks/Microsoft.NET.Build.Tasks/ResolvePackageAssets.cs	Implements analyzer resolution from the lock-file analyzers group (when enabled) and adds metadata-based language/compiler-version selection.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 2

[martinrrm]

@dotnet/dotnet-cli Hi! Who would be a good reviewer for this change other than nuget team? Thanks!

[dsplaisted]

It sounds like you can't opt in to the new behavior for .NET 10 and lower. Why is that? Does something break about the behavior in that case?