Add analyzer section in project.assets.json file by martinrrm · Pull Request #7464 · NuGet/NuGet.Client

martinrrm · 2026-06-08T23:06:58Z

Bug

Progress: NuGet/Home#6279
SDK PR (draft): dotnet/sdk#54646

Description

Today project.assets.json does not record which analyzers a package contributes, and analyzers are applied regardless of PrivateAssets / ExcludeAssets / IncludeAssets. This PR implements the NuGet restore half of the "indicate analyzer assets in project.assets.json" feature (spec: NuGet/Home#14455). The SDK consumption half ships as a separate dotnet/sdk PR.

When a project opts in with <RestoreEnableAnalyzerAssets>true</RestoreEnableAnalyzerAssets>, restore now:

Emits an analyzers group under each package in the assets file, listing every analyzer assembly. Detection uses a new AnalyzerAssemblies pattern in ManagedCodeConventions (any .dll under analyzers/ at any depth, excluding satellite .resources.dll), so the layout isn't assumed to be fixed and analyzer discovery is shared with the rest of the content model.
Respects asset filtering. PrivateAssets, ExcludeAssets, and IncludeAssets filter analyzers like any other asset type. Analyzers excluded or transitively suppressed are written as a _._ placeholder (consistent with compile / runtime / native).
Attaches selection metadata to each entry: codeLanguage (cs/vb/fs/any) and, when present in the path, compilerApiVersion (roslynX.Y) — mirroring how content files carry codeLanguage — so the SDK selects applicable analyzers from metadata instead of parsing paths. The metadata is derived by scanning the path segments, since real packages place the language at a variable depth (for example analyzers/dotnet/roslynX.Y/cs/).

Gating. The feature is opt-in and only honored for projects targeting .NET 11 or greater. The .NET 11+ gate is applied at evaluation time in NuGet.targets (mirroring NuGetAuditMode), and the resulting value is honored per target framework: it flows through TargetFrameworkInformation.RestoreEnableAnalyzerAssets and is read in code by every restore entry point — CLI/DG-spec (MSBuildRestoreUtility), VS nomination (PackageSpecFactory), and static-graph restore (MSBuildStaticGraphRestore, which previously did not honor the property at all). A multi-targeted net10.0;net11.0 project therefore emits the analyzers group only for net11.0.

Telemetry. ProjectRestoreInformation reports AnalyzerAssets.Enabled (opt-in state) and AnalyzerAssets.Count (number of analyzer assets emitted, excluding _._ placeholders). Richer adoption/impact telemetry to inform the default-on rollout ships as a follow-up.

Public API & serialization. Adds TargetFrameworkInformation.RestoreEnableAnalyzerAssets, LockFileTargetLibrary.AnalyzerAssets, LockFileItem.CompilerApiVersionProperty, and the ManagedCodeConventions.ManagedCodePatterns.AnalyzerAssemblies pattern (with the AnalyzerAssembly property name). The Newtonsoft.Json and System.Text.Json paths round-trip the new analyzers group and its metadata; the per-framework restore property round-trips through PackageSpecWriter and the streaming reader. The lock-file cache key includes the per-framework flag so toggling it invalidates correctly.

PR Checklist

Meaningful title, helpful description and a linked NuGet/Home issue
Added tests
Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

jebriede

Approving with a few suggestions.

jebriede · 2026-06-09T21:12:30Z

+        private static bool IsAnalyzerAssetPath(string path)
+        {
+            return path.StartsWith("analyzers/", StringComparison.Ordinal)
+                && path.EndsWith(".dll", StringComparison.OrdinalIgnoreCase)


The "analyzers/" prefix check is StringComparison.Ordinal (case-sensitive) while the .dll / .resources.dll checks are OrdinalIgnoreCase. If a package authored the folder as Analyzers/ this would skip it while the SDK's discovery (which we're mirroring) may still pick it up. Was case-sensitivity on the folder segment intentional? If not, consider OrdinalIgnoreCase for consistency with the extension checks.

Yes this was intentional, we are mirroring sdk analysis discovery from https://github.com/dotnet/sdk/blob/8283adc1579c8bc2afb4458c81cbda0c6eac4466/src/Common/NuGetUtils.NuGet.cs#L43-L53.

jebriede

Approving with an optimization suggestion.

nkolev92

I think we're introducing a new implementation pattern in a couple of different places, but we already have an established one.

nkolev92 · 2026-06-16T00:37:16Z

+            return lockFileItems;
+        }
+
+        private static bool IsAnalyzerAssetPath(string path)


I think we should be using ManagedCodeConventions here.

That's what knows how to find the patterns.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/ContentModel/ManagedCodeConventions.cs

Lines 529 to 540 in d66371a

NativeLibraries = new PatternSet(

conventions.Properties,

groupPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any?}", table: DotnetAnyTable),

new PatternDefinition("runtimes/{rid}/native/{any?}", table: null, defaults: DefaultTfmAny)

},

pathPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any}", table: DotnetAnyTable),

new PatternDefinition("runtimes/{rid}/native/{any}", table: null, defaults: DefaultTfmAny)

});

Added an AnalyzerAssemblies PatternSet to ManagedCodeConventions (a terminal {analyzerAssembly} token matching any .dll under analyzers/ at any depth, excluding .resources.dll satellites) and removed the hand-rolled IsAnalyzerAssetPath .

GetAnalyzerLockFileItems now consumes contentItems.FindItems(...). I kept the metadata derivation (codeLanguage / compilerApiVersion) as a segment scan rather than content-model patterns, because the pattern engine extracts properties at fixed positions and the language segment isn't at a fixed position in practice.

I sampled 12 popular analyzer packages (67 analyzer DLLs): 66% put the language after the compiler version (analyzers/dotnet/roslynX.Y/cs/…), with the language appearing at depth 1, 2, or 3 depending on the package. Expressing that in the content model would need an enumerated set of depth-specific patterns plus new parsers and would silently mis-tag anything deeper. The scan handles all positions uniformly. Happy to revisit if you'd prefer the pattern approach.

Looking at the implementation, it looks like we can add multiple PatternDefinition(s) to locate analyzer assemblies. For example, the below implementation shows that there are 3 patterns to identify a runtime assembly. If we know the exact patterns for analyzers, then I think we can add multiple patterns to locate the analyzer assembly.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/ContentModel/ManagedCodeConventions.cs

Lines 490 to 503 in 58868fa

RuntimeAssemblies = new PatternSet(

conventions.Properties,

groupPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/lib/{tfm}/{any?}", table: DotnetAnyTable),

new PatternDefinition("lib/{tfm}/{any?}", table: DotnetAnyTable),

new PatternDefinition("lib/{assembly?}", table: DotnetAnyTable, defaults: NetTFMTable)

},

pathPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/lib/{tfm}/{assembly}", table: DotnetAnyTable),

new PatternDefinition("lib/{tfm}/{assembly}", table: DotnetAnyTable),

new PatternDefinition("lib/{assembly}", table: DotnetAnyTable, defaults: NetTFMTable)

});

I agree with @kartheekp-ms
I think it's possible to use mutliple pattern definitions.

Or at least we should try. That way we don't have to worry about maintainbility of that code at all, since it's generic.

Did you have a chance to try this out?

nkolev92 · 2026-06-16T00:37:58Z

        /// the group has items. Empty groups are left alone.
        /// </summary>
-        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory) where T : LockFileItem
+        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory, bool copyProperties = true) where T : LockFileItem


Can you explain what are the properties we're stopping from copying in the analyzers scenario?

The analyzer LockFileItems carry two metadata properties codeLanguage (cs / vb / fs / any) and, when present, compilerApiVersion ( roslynX.Y )

So we're basically removing this for analyzers?

Aren't those analyzer specific?

dotnet-policy-service · 2026-06-25T19:25:32Z

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

…ventions detection Move the RestoreEnableAnalyzerAssets opt-in gating into code, per target framework. The value now flows through TargetFrameworkInformation and is read by every restore entry point, including static-graph restore which previously ignored the property entirely. Removes the project-level ProjectRestoreMetadata.RestoreEnableAnalyzerAssets and the NuGet.targets OR. Detect analyzers via a new AnalyzerAssemblies pattern in ManagedCodeConventions instead of the hand-rolled IsAnalyzerAssetPath, so detection is shared with the content model and matches the analyzers folder case-insensitively. Clarify the analyzer metadata derivation comment and trim an allocation in the compiler-version normalization. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add five properties to the ProjectRestoreInformation event to size the impact of enabling RestoreEnableAnalyzerAssets by default before the rollout: - AnalyzerAssets.Excluded.Count - AnalyzerAssets.PackagesWithAnalyzers.Count - AnalyzerAssets.PackagesWithExcludedAnalyzers.Count - AnalyzerAssets.ExcludedByPrivateAssets.Count - AnalyzerAssets.ExcludedByExcludeAssets.Count The counts are derived from the resolved dependency graphs and the package file lists, so they are reported on every full restore regardless of whether the feature is currently enabled. This lets us measure how many packages and analyzer assemblies would stop being applied once PrivateAssets/ExcludeAssets are honored. AnalyzerAssets.Count is redefined as the number of analyzer assemblies that would apply (computed the same way), replacing the previous count of analyzer assets written to the assets file. Analyzer detection mirrors ManagedCodeConventions.ManagedCodePatterns. AnalyzerAssemblies as a cheap string check, avoiding a content-item collection allocation per package on the restore path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address spec review feedback (Client.Engineering#3855): the rollout decision is driven by whether a package's analyzers are affected, not by how many individual analyzer assemblies it ships. - Remove AnalyzerAssets.Count (per-assembly applied count). - Replace AnalyzerAssets.Excluded.Count with a binary AnalyzerAssets.Excluded (true when any package's analyzers would be filtered out for the project). The package-level counts (PackagesWithAnalyzers.Count, PackagesWithExcludedAnalyzers.Count, ExcludedByPrivateAssets.Count, ExcludedByExcludeAssets.Count) are unchanged. Per-package detection now uses a HashSet rather than per-assembly counts. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address PR feedback (#7464): use the NoAllocEnumerate helper for the IList iterations in PopulateAnalyzerAssetsTelemetry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address PR feedback (#7464): look up TargetFrameworkInformation by (framework, alias) via GetNearestTargetFramework instead of framework-only, in LockFileBuilder and the analyzer-assets telemetry, so multi-targeted projects with aliased frameworks resolve to the correct target framework. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address PR feedback (#7464): treat RestoreEnableAnalyzerAssets as a project-wide opt-in instead of per target framework. When any target framework opts in, analyzer assets are honored for every target framework, mirroring how package pruning is enabled project-wide once any framework qualifies (PackageSpecFactory.GetPackagePruningDefault). The per-framework opt-in is already gated to .NET 11+ in NuGet.targets, so only a qualifying framework can enable it. Add a multi-targeted restore test asserting a non-opted-in framework still honors analyzers when another framework opts in. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address PR feedback (#7464): analyzer assets restore was force-disabled below .NET 11 even when explicitly opted in. Mirror package pruning instead — default to off, but honor an explicit RestoreEnableAnalyzerAssets opt-in (or opt-out) on any target framework, so users can opt into the new behavior before it is enabled by default. The net11 version gate only ever forced off the explicit opt-in; a future default-on can gate itself the way RestorePackagePruningDefault does. Update the availability tests: the opt-in is now honored on all frameworks, and the value defaults to false when unset. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

nkolev92 · 2026-07-03T19:32:59Z

            Imports = cloneFrom.Imports;
            AssetTargetFallback = cloneFrom.AssetTargetFallback;
            Warn = cloneFrom.Warn;
+            RestoreEnableAnalyzerAssets = cloneFrom.RestoreEnableAnalyzerAssets;


I think I brought it up somewhere else, but I'm curious what @zivkan thinks too.

I'm wondering if this should be on https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs, similar to CPM, Audit and other non TFM props.

Pruning has props that are per project and this doesn't.

nkolev92 · 2026-07-03T19:34:38Z

                    TargetAlias = targetAlias,
-                    Warn = warn
+                    Warn = warn,
+                    RestoreEnableAnalyzerAssets = msBuildProjectInstance.IsPropertyTrue("RestoreEnableAnalyzerAssets")


See other comment, the equivalent would be RestoreAuditProperties and GetRestoreAuditProperties in MSBuildRestoreUtility.

nkolev92 · 2026-07-03T20:03:32Z

+            return lockFileItems;
+        }
+
+        private static bool IsAnalyzerAssetPath(string path)


Did you have a chance to try this out?

nkolev92 · 2026-07-03T20:04:55Z

        /// the group has items. Empty groups are left alone.
        /// </summary>
-        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory) where T : LockFileItem
+        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory, bool copyProperties = true) where T : LockFileItem


So we're basically removing this for analyzers?

Aren't those analyzer specific?

martinrrm requested a review from a team as a code owner June 8, 2026 23:06

martinrrm requested review from kartheekp-ms and zivkan June 8, 2026 23:06

jebriede previously approved these changes Jun 9, 2026

View reviewed changes

martinrrm mentioned this pull request Jun 9, 2026

[spec] Indicate analyzer assets and respect analyzer filtering in project.assets.json NuGet/Home#14455

Open

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/LockFileUtils.cs Outdated

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.ProjectModel/LockFile/LockFileFormat.cs

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests/RestoreCommandTests.cs

martinrrm dismissed jebriede’s stale review via 95dcd89 June 15, 2026 18:21

martinrrm requested review from jebriede and kartheekp-ms June 15, 2026 20:44

jebriede previously approved these changes Jun 15, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.Commands/RestoreCommand/RestoreCommand.cs Outdated

nkolev92 reviewed Jun 16, 2026

View reviewed changes

kartheekp-ms reviewed Jun 16, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/LockFileUtils.cs

dotnet-policy-service Bot added the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Jun 25, 2026

martinrrm removed the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Jun 25, 2026

martinrrm dismissed jebriede’s stale review via 6d6559e June 25, 2026 23:36

martinrrm and others added 3 commits June 25, 2026 16:48

Add analyzer section in project.assets.json

592aa22

PR comments

cfb837e

martinrrm force-pushed the dev-mruizmares-analyzer-assets branch from 6d6559e to 963cbee Compare June 26, 2026 00:05

martinrrm force-pushed the dev-mruizmares-analyzer-assets branch from 963cbee to b7099ed Compare June 26, 2026 00:42

martinrrm requested review from jebriede, kartheekp-ms and nkolev92 June 26, 2026 00:42

nkolev92 reviewed Jun 30, 2026

View reviewed changes

martinrrm and others added 2 commits June 30, 2026 11:05

Use NoAllocEnumerate in analyzer-assets telemetry loops

7e5bbab

Address PR feedback (#7464): use the NoAllocEnumerate helper for the IList iterations in PopulateAnalyzerAssetsTelemetry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

martinrrm and others added 2 commits June 30, 2026 11:39

martinrrm requested a review from nkolev92 July 2, 2026 20:36

nkolev92 reviewed Jul 6, 2026

View reviewed changes

	NativeLibraries = new PatternSet(
	conventions.Properties,
	groupPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any?}", table: DotnetAnyTable),
	new PatternDefinition("runtimes/{rid}/native/{any?}", table: null, defaults: DefaultTfmAny)
	},
	pathPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any}", table: DotnetAnyTable),
	new PatternDefinition("runtimes/{rid}/native/{any}", table: null, defaults: DefaultTfmAny)
	});

	RuntimeAssemblies = new PatternSet(
	conventions.Properties,
	groupPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/lib/{tfm}/{any?}", table: DotnetAnyTable),
	new PatternDefinition("lib/{tfm}/{any?}", table: DotnetAnyTable),
	new PatternDefinition("lib/{assembly?}", table: DotnetAnyTable, defaults: NetTFMTable)
	},
	pathPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/lib/{tfm}/{assembly}", table: DotnetAnyTable),
	new PatternDefinition("lib/{tfm}/{assembly}", table: DotnetAnyTable),
	new PatternDefinition("lib/{assembly}", table: DotnetAnyTable, defaults: NetTFMTable)
	});

Uh oh!

Conversation

martinrrm commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bug

Description

PR Checklist

Uh oh!

jebriede left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jebriede left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nkolev92 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nkolev92 Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dotnet-policy-service Bot commented Jun 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

martinrrm commented Jun 8, 2026 •

edited

Loading

nkolev92 Jun 30, 2026 •

edited

Loading