Update MSBL001 to recommend ExcludeAssets="runtime" and PrivateAssets="all"

[Copilot]

ExcludeAssets="runtime" alone doesn't prevent package reference metadata from flowing transitively to downstream projects. Projects referencing a library with MSBuild packages still get runtime assets, triggering MSBL001 even when the library correctly excludes them.

Adding PrivateAssets="all" prevents the reference from flowing to consumers entirely—the right behavior since MSBuildLocator handles finding these assemblies at runtime.

Changes

• Microsoft.Build.Locator.targets: Updated MSBL001 error message to suggest both attributes
• docs/diagnostics/MSBL001.md: Updated documentation to explain transitive flow issue and show corrected solution

Solution

<PackageReference Include="Microsoft.Build" ExcludeAssets="runtime" PrivateAssets="all" />
<PackageReference Include="NuGet.Frameworks" ExcludeAssets="runtime" PrivateAssets="all" />

Fixes #364

Original prompt

---

This section details on the original issue you should resolve

<issue_title>MSBL001 issued when referencing NuGet.ProjectModel in a project also making use of Microsoft.Build.Locator</issue_title>
<issue_description>See https://github.com/sensslen/nuget-license/actions/runs/19501203094/job/55815524334?pr=338 for the error that is reported. This starts happening when updating the locator from 1.10.12 to 1.11.1. When I try to overwrite the NuGet.Frameworks package by explicitely referencing the package in my project, the issue still manifests.

How can I resolve this issue?
I do need the Nuget.ProjectModel dependency to properly read restored packages</issue_description>

<agent_instructions>Fix this issue by having the MSBL001 diagnostic suggest setting ExcludeAssets="runtime" and PrivateAssets="all" for the impacted dependencies. Also update the diagnostic code documentation for MSBL001 to match, and any other relevant documentation or links in the repo.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@YuliiaKovalova @baronfel could you please check this issue? @baronfel This is a bad experience that arises because PackageReference ExcludeAssets metadata doesn't transitively flow.

In this repo, the dependency chain looks like this

• NuGetUtility.csproj references MSBuildLocator and MSBuild runtime packages
• NuGetLicense.csproj (and others) reference NuGetUtility.csproj

Even if NuGetUtility does the right thing to mitigate this issue and adds an explicit PackageReference Include="NuGet.Frameworks" Version="7.0.0" ExcludeAssets="runtime" />, the other Projects do not get that metadata.

To really fix this, every Project that is 'downstream' of NuGetUtility needs to add a similar explicit PackageReference.

This is a really poor UX, but I haven't been able to find ways of programmatically doing the right thing here. The problem is that we need to

• detect if NuGet.Frameworks is referenced directly or indirectly by a Project
• modify the ExcludeAssets metadata of that PackageReference if direct, or synthesize a direct PackageReference if indirectly referenced
• do this all before the Restore Target so that Restore can write correct project.assets.json files for all the projects

This seems to be very hard if not impossible to do at this time. Calling in the big guns (@jeffkl @nkolev92) for any advice they may have.</comment_new>
<comment_new>@rainersigwald
What if NuGetUtility additionally declares PrivateAssets for NuGet.Frameworks?</comment_new>
<comment_new>@baronfel
@rainersigwald Uh, that worked from a build perspective ... why would that work? I see that it's removed the NuGet.Framework dependency entirely from the 'targets' of the project.assets.json, and it also doesn't appear in the deps.json for any of the apps built from this repo. This puzzles me - I expect NuGet.Frameworks to still be required for the app to run correctly, so to me that means it should be in the deps.json.

@sensslen adding <PackageReference Include="NuGet.Frameworks" Version="7.0.0" ExcludeAssets="runtime" PrivateAssets="all" /> should address your issue.</comment_new>
<comment_new>@rainersigwald
But we want to find it at runtime via Locator, right? So I think it is "not a real dependency" of NuGetUtility.dll from the perspective of consuming projects, because NuGetUtility will handle finding it itself (via the MSBuildLocator call).</comment_new>
<comment_new>@baronfel
@rainersigwald I guess then my follow-on question would be why Private isn't the recommendation for the MSBuild packages as well - I don't have a solid intuition for what that means for downstream projectreferences.</comment_new>
<comment_new>@rainersigwald
Yes, I think we should probably change Locator to encourage this for all of the packages/assemblies on its list.</comment_new>
<comment_new>@rainersigwald
@sensslen did you get a chance to try the suggestion here? #364 (comment)</comment_new>

• Fixes MSBL001 issued when referencing NuGet.ProjectModel in a project also making use of Microsoft.Build.Locator #364

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.