search

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.66k stars 1.06k forks source link

`dotnet workload restore` has odd logging and ignores logging switches #42485

Open AArnott opened 1 month ago

AArnott commented 1 month ago

dotnet workload restore is a real oddball. Besides being uniquely able to repro such bugs as dotnet/msbuild#10468, it has an odd console logging style, and it ignores the -bl switch.

Repro

Works

dotnet workload restore

Fails

dotnet workload restore -bl

Couldn't find a project. Ensure that a project exists in C:\Users\andarno\source\repos\Library.Template\azure-pipelines, or pass the path to the project using --project.

Ignores switch

dotnet workload restore -bl .\dirs.proj

The added dirs.proj argument gets the command to run, but it ignores the -bl switch: no msbuild.binlog file is created.

baronfel commented 1 month ago

The oddities you're seeing are because it's not a normal MSBuild-driven command - MSBuild if anything is an implementation detail and unfortunate incidences like dotnet/msbuild#10468 are the exception, not the norm. We probably should have some better way to get diagnostics from it, but I wouldn't immediately reach for using the MSBuild mechanisms for these things due to the different nature of this command.

AArnott commented 1 month ago

I also note that /p:NoWarn=MSB3982 added to dotnet workload restore is ignored. The warnings are still emitted.

marcpopMSFT commented 1 week ago

We need to do a pass over our commands and separate them into the msbuild vs. not. It might be good in the non-msbuild commands to actually catch -p /bl or other usage and warn the customer. This is on the backlog for now.