Workloads commands (and other implicit msbuild usage) should not share msbuild warnings by default (only in /bl or diag mode)

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI

https://dot.net/core

MIT License

2.7k stars 1.06k forks source link

Workloads commands (and other implicit msbuild usage) should not share msbuild warnings by default (only in /bl or diag mode) #43355

Open JanKrivanek opened 1 month ago

JanKrivanek commented 1 month ago

Context

This is followup on https://github.com/dotnet/msbuild/issues/10468 Adding /p:NoWarn=MSB3982 to dotnet workload restore is ignored - it's not passed through to msbuild. Ideally the parameter would be flagged as not supported, or otherwise passed through to msbuild

nagilson commented 1 week ago

Adding to team triage to decide priority.

marcpopMSFT commented 1 week ago

I changed the title as there are a set of .net cli commands that we do not want the customer to have visibility into how it's implemented and there's no reason to expose the MSBuild usage. Potentially, we might even want to suppress env processing in MSBuild but perhaps that's a step too far.

Either way, we'd want a way to get this back in case we need it for diagnostics in the future. moving to net10.

nagilson commented 1 week ago

Baronfel: In the simplest form, it might be as easy as setting a few more properties here where we call MSBuild on the projects: https://github.com/dotnet/sdk/blob/8634876e54cb129ae59728ea87c1990bc88b3f35/src/Cli/dotnet/commands/dotnet-workload/restore/WorkloadRestoreCommand.cs#L77-L80 WorkloadRestoreCommand.cs dotnet/sdk

e.g. TreatWarningsAsErrors, "false"