--no-restore should specify -restore:false when calling MSBuild to override response file arguments

[jeffkl]

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

When running commands that accept --no-restore, a repository with a Directory.Build.rsp will still inject its own -restore argument. I think when I specify something like:

dotnet test --no-restore

That the call to MSBuild should include the -restore:false command-line argument to override the arguments in my Directory.Build.rsp. Otherwise, I have to specify it myself which looks funny:

dotnet test --no-restore -restore:false

Describe the solution you'd like

Commands that use RestoringCommand could check for the option and set the MSBuild command-line argument.

For example:

sdk/src/Cli/dotnet/commands/dotnet-build/BuildCommand.cs

Lines 50 to 55 in daa9384

	bool noRestore = parseResult.GetResult(BuildCommandParser.NoRestoreOption) is not null;
	BuildCommand command = new(
	msbuildArgs,
	noRestore,
	msbuildPath);

bool noRestore = parseResult.GetResult(BuildCommandParser.NoRestoreOption) is not null;

+ if (noRestore)
+ {
+     msbuildArgs.Add("-restore:false");
+ }

BuildCommand command = new(
    msbuildArgs,
    noRestore,
    msbuildPath);

Or perhaps the argument itself could be marked to forward in such a way?

sdk/src/Cli/dotnet/commands/dotnet-build/BuildCommandParser.cs

Line 39 in daa9384

public static readonly CliOption<bool> NoRestoreOption = CommonOptions.NoRestoreOption;

- public static readonly CliOption<bool> NoRestoreOption = CommonOptions.NoRestoreOption;
+ public static readonly CliOption<bool> NoRestoreOption = new ForwardedOption<bool>("--no-restore").FowardedAs("-restore:false");

Additional context

I'm trying to streamline the build in the NuGet client repo and because we have a Directory.Build.rsp which injects -restore so that when you run MSBuild.exe you get the implicit restore, other commands where I don't want to restore I have to use both --no-restore and -restore:false.

I'd be willing to contribute if this a change that would be accepted.

[baronfel]

This seems useful to me - the second approach with the ForwardedOption seems more natural to the way the codebase is designed right now.

[marcpopMSFT]

Triage: @jeffkl this change seems reasonable and the forwarded options as Chet described would be a good way to do it. Feel free to put up a PR into main.

[jeffkl]

Thanks, please review at #40579