Support suppression of package-specific NETSDK warnings on package level

[kamaleybov]

Is your feature request related to a problem? Please describe.

We are upgrading a solution from .NET 6 to .NET 8. After the upgrade we started getting NETSDK1206 warning for one of the packages (Microsoft.Azure.DocumentDB.Core), which we decided to suppress for now. But it seems like that warning can only be suppressed at project level, while we would like to suppress it for just that one package. We want to make sure that if at any point going forward another package with the same issue gets introduced, we would not overlook it.

Repro

Project file, foo.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net9.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.Azure.DocumentDB.Core" Version="2.22.0" />
    </ItemGroup>
</Project>

Build & warning (formatted a bit):

> dotnet build foo.csproj

Restore complete (0.2s)
  foo succeeded with 1 warning(s) (1.5s) → bin\Debug\net9.0\foo.dll
    C:\Program Files\dotnet\sdk\9.0.102\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(322,5):
    warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): win7-x64.
    Affected libraries: Microsoft.Azure.DocumentDB.Core. In .NET 8.0 and higher, assets for version-specific
    and distribution-specific runtime identifiers will not be found by default.
    See https://aka.ms/dotnet/rid-usage for details.

Build succeeded with 1 warning(s) in 2.2s

Can be suppressed with project-level NoWarn

Project file, foo.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net9.0</TargetFramework>
        <NoWarn>NETSDK1206</NoWarn>                  <!-- added -->
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.Azure.DocumentDB.Core" Version="2.22.0" />
    </ItemGroup>
</Project>

Build:

> dotnet build foo.csproj

Restore complete (0.3s)
  foo succeeded (0.3s) → bin\Debug\net9.0\foo.dll

Build succeeded in 1.1s

Package-level NoWarn is ignored

Project file, foo.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net9.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.Azure.DocumentDB.Core" Version="2.22.0" NoWarn="NETSDK1206" />  <!-- added: NoWarn -->
    </ItemGroup>
</Project>

Build & warning (formatted a bit):

> dotnet build foo.csproj

Restore complete (0.3s)
  foo succeeded with 1 warning(s) (0.3s) → bin\Debug\net9.0\foo.dll
    C:\Program Files\dotnet\sdk\9.0.102\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(322,5):
    warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): win7-x64.
    Affected libraries: Microsoft.Azure.DocumentDB.Core. In .NET 8.0 and higher, assets for version-specific
    and distribution-specific runtime identifiers will not be found by default.
    See https://aka.ms/dotnet/rid-usage for details.

Build succeeded with 1 warning(s) in 1.0s

Describe the solution you'd like

We would like to have a way to suppress NETSDK1206 at package level, either through NoWarn attribute on PackageReference element, or through other means.

Glancing through other .NET SDK warnings, there are some that apply to specific packages - it might make sense to implement package-level NoWarn support for all such warnings.

[baronfel]

This seems like a reasonable request. Most handling of PackageReference/PackageVersion items and their metadata is handled by NuGet today during Restore, resulting in a project.assets.json file that we read in ResolvePackageAssets.cs. I think we would need to coordinate changes here with the NuGet team so that metadata like NoWarn could be applied to transitive references of packages (i.e. how PrivateAssets and other metadata flow today).

cc @nkolev92 @zivkan @dsplaisted

[nkolev92]

I agree, we'd need to coordinate the design here.

A couple of things about the lay of the land today.

• NoWarn does not apply transitively. Tracking at NoWarn on a package reference does not apply transitively to its dependencies NuGet/Home#5740
• PrivateAssets does not apply transitively, but it rather stops transitivity.
• IncludeAssets/ExcludeAssets apply transitively and those are within restore.

[baronfel]

I'm also really struggling to rationalize from an MSBuild perspective how we even generalize this data. The specific example of NETSDK1206 isn't a package specific error, it's an error raised when looking at a specific runtime asset. We'd have to trace from this runtime asset to the package it came from to determine if the warning should be logged. We can do this because we have the Assets File as an input to the Task. It's entirely possible that other SDK warnings might not be as easy to reconstruct the same chain of logic, though. @kamaleybov are there other specific warnings that you'd considered needing to stifle in this same way?

[kamaleybov]

are there other specific warnings that you'd considered needing to stifle in this same way?

@baronfel, we didn't hit any others (yet).

[kfertitta]

I'd like to vote up this feature request, as we a pretty compelling use case. We very recently reported a nasty bug in Microsoft.CodeAnalysis.Workspaces.MSBuild which causes a warning to be emitted but which, we're told by the team, can safely be ignored until a fix is in place. It seems it will require some time to resolve and we cannot proceed without it, so it seems our only alternative is to silence all of these warnings. Very risky for us to proceed that way for any non-trivial period of time.

[marcpopMSFT]

@kfertitta what warning were you hitting? Was it different than the original person?

Triage: If we know the package impacted by a warning (which we appear to for the first one) we could potentially pipe some information through to suppress. We'd need to review warning by warning and customize it for this particular warning which seems a bit of a hacky solution. I am moving to the backlog for now as we wait for more feedback.

[kfertitta]

@marcpopMSFT I am getting MSB3277

I can see it with a minimal C# class library project in Dev 17.12.4.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis" Version="4.12.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Common" Version="4.12.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.12.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Workspaces.Common" Version="4.12.0" />
    <PackageReference Include="Microsoft.CodeAnalysis.Workspaces.MSBuild" Version="4.12.0" />
  </ItemGroup>

</Project>