How to fail the run if NuGet restored with warnings?

[mstefarov]

I ran into several cases where I accidentally benchmarked the wrong version of a NuGet package because NuGet restore warnings (e.g. NU1102 "Unable to find package 'Foo' with version (>= X.Y.Z)" or NU1603 "An approximate best match of X.Y.Z was resolved.") were not reported by BenchmarkDotNet when I use CsProjClassicNetToolchain or CsProjCoreToolchain, and these warnings did not fail the build/run.

I've been looking for a way to treat these warnings as errors, but have not found a way yet.

• <WarningsAsErrors>NU1102;NU1603</WarningsAsErrors> in the benchmark csproj has no effect, because it does not get copied over to generated projects.
• Passing /p:WarningsAsErrors="NU1102;NU1603" as an MsBuildArgument to the job does not work, because BenchmarkDotNet uses dotnet restore (which does not respect this option) instead of nuget restore or msbuild /t:Restore (which would).

Is there another way, short of forking CsProj toolchains?

IMO treating NuGet restore problems as run failures seems like a resonable default behavior too.

[timcassell]

I'm surprised dotnet restore ignores that property. Probably a simple solution would be to copy the WarningsAsErrors property from the csproj. https://github.com/dotnet/BenchmarkDotNet/blob/6a7244d76082f098a19785e4e3b0e0f269fed004/src/BenchmarkDotNet/Toolchains/CsProj/CsProjGenerator.cs#L26-L39

Alternatively, adding <WarningsAsErrors>NU1102;NU1603</WarningsAsErrors> to the csproj template could also work.

I don't have an opinion as to which would be the better option.