nuget audit warnings report and counted twice

[WeihanLi]

Describe the bug

nuget audit warning reports and counted twice

To Reproduce

Reproduce sample project: https://github.com/WeihanLi/SamplesInPractice/tree/main/NuGetSamples

Just run dotnet build

Exceptions (if any)

Further technical details

• Include the output of dotnet --info

.NET SDK:
 Version:           9.0.101
 Commit:            eedb237549
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.12+1cce77968

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.101\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.13.35507.96
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  6.0.428 [C:\Program Files\dotnet\sdk]
  8.0.206 [C:\Program Files\dotnet\sdk]
  8.0.307 [C:\Program Files\dotnet\sdk]
  9.0.100-rc.2.24474.11 [C:\Program Files\dotnet\sdk]
  9.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0-rc.2.24474.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[marcpopMSFT]

@zivkan @Nigusu-Allehu should we route folks to report these in the nuget repo?

[Nigusu-Allehu]

I was able to reproduce this issue for dotnet pack and dotnet run. I think moving NugetAudit related issues to the NuGet repo makes sense

[zivkan]

@marcpopMSFT I think our teams need a quick sync on how we can solve this problem. So, it doesn't really matter to me which repo it's in. NuGet logs one of the messages, an MSBuild task living in the sdk repo logs the second message.

When a customer runs dotnet build without --no-restore, is there a way for restore to know that a build is going to happen immediately afterwards? Or can ResolvePackageAssets know that the restore target already ran? If so, then one of these two should stop logging the messages.

Otherwise, perhaps an option is to change ResolvePackageAssets to replay NuGet's warning/error messages only in Visual Studio. This will have the side effect that dotnet build --no-restore will stop outputting the messages. Since restore didn't run, I think that's ok, but I'm not going to take responsibility for making that decision alone, so that's something we'd need to discuss with more people and get agreement on. Maybe some people like getting nuget warnings/errors when they build with --no-restore?

The design of SDK style projects in Visual Studio is that NuGet does not log to VS's Error List, it instead writes the messages to the assets file, the SDK task replays the messages when the project system does a design time build, and the project system adds the messages to the error list. In other words, we can't stop ResolvePackageAssets from replaying the messages, it's a core part of the design of how it's designed in Visual Studio.

There might be other ways to implement a fix that I can't think of, so ideas from other people would be nice.

[marcpopMSFT]

So basically the restore is throwing the warning as is the build (from reading the assets file)? @dsplaisted in case you have any ideas or if this should be a partner sync topic.

[dsplaisted]

Maybe the ideal thing would be to stop producing these errors and warnings from ResolvePackageAssets if we're running outside of Visual Studio and restore already ran in this command invocation. I'm not sure if we have a good way to check if restore ran though, we might need a change to MSBuild to add a property to the main build if /restore was used.

@rainersigwald

[WeihanLi]

Is it possible to check the error code and source code location to avoid duplicate warning/error? That may also benefit other cases not only the nuget audit case here.