fix(#45761): Stop forwarding dotnet-watch run arguments to all commands #50558

ronald-mz · 2025-08-30T05:01:21Z

Fixes: #45761, #45634, and maybe a regression of #34949.

Context

Watch CLI

dotnet watch [<command>]
  [--list]
  [--no-hot-reload] [--non-interactive]
  [--project <PROJECT>]
  [-q|--quiet] [-v|--verbose]
  [--version]
  [--] <forwarded arguments> 

dotnet watch -?|-h|--help

Problem

dotnet-watch has -p, --project, --launch-profile, and --no-launch-profile as possible arguments. A user can not use these arguments without dotnet-watch forwarding them. These arguments only work with the run command, and will cause an error if passed to any command but run.

…ll commands

ronald-mz · 2025-08-30T05:04:51Z

@dotnet-policy-service agree

ronald-mz · 2025-08-30T05:07:49Z

src/BuiltInTools/dotnet-watch/CommandLine/CommandLineOptions.cs

            var optionResult = (OptionResult)child;

            // skip watch options:
-            if (!watchOptions.Contains(optionResult.Option))


Inverting the logic allows a continue to short-circuit the loop.

ronald-mz · 2025-08-30T05:08:40Z

src/BuiltInTools/dotnet-watch/CommandLine/CommandLineOptions.cs

+            }
+
+            // skip forwarding run options to other commands.
+            if (isRunCommand == false && forwardToRunOptions.Contains(optionResult.Option))


The meat and potatoes of this PR. Prevents options which only work with the run command from being passed to other commands.

nit: !isRunCommand

Can we pass command from the caller and generalize this to if (forwardToSubcommandOptions.Contains(optionResult.Option) && !command.Options.Contains(optionResult.Option)) ?

Of course. Give me a bit and I'll get some commits up.

Further Thoughts

This is outside the scope of this fix, but a different PR could go a step further towards generalization by:
nixing forwardToSubcommandOptions in favor of watchableSubCommandOptions.

watchableSubCommandOptions are options that can show up in subcommands that could affect watch's settings.

For example: run --project and build [<PROJECT>|<SOLUTION>] could both set watch's project path.

…profile

tmat · 2025-09-02T15:11:05Z

src/BuiltInTools/dotnet-watch/CommandLine/CommandLineOptions.cs

            }
        });

+        // Options we need to know about that are passed through to the subcommand:


add ... if the subcommand supports them

tmat · 2025-09-02T15:16:42Z

src/BuiltInTools/dotnet-watch/CommandLine/CommandLineOptions.cs

-        var longProjectOption = new Option<string>("--project") { Hidden = true, Arity = ArgumentArity.ZeroOrOne, AllowMultipleArgumentsPerToken = false };
-        var launchProfileOption = new Option<string>("--launch-profile", "-lp") { Hidden = true, Arity = ArgumentArity.ZeroOrOne, AllowMultipleArgumentsPerToken = false };
-        var noLaunchProfileOption = new Option<bool>("--no-launch-profile") { Hidden = true, Arity = ArgumentArity.Zero };
+        Option[] forwardToRunOptions =


I'd call this forwardToSubcommandOptions

Nit: You can replace https://github.com/dotnet/sdk/pull/50558/files#diff-6a6fa2fea5af87fda145d79165f529cef772a3227d58494098b7a22511c4aecaR96-R99 with

foreach (var option in forwardToSubcommandOptions) { rootCommand.Options.Add(option); }

Youssef1313 · 2025-09-12T08:06:30Z

src/BuiltInTools/dotnet-watch/CommandLine/CommandLineOptions.cs

+            }
+
+            // skip forwarding run options to other commands.
+            if (isRunCommand == false && forwardToRunOptions.Contains(optionResult.Option))


This is very concerning to me. Are we ignoring --project completely? That's worse than producing an error.

Also, it means we might be regressing the scenario for the MTP-based dotnet test which actually accepts --project.

@tmat I don't have much context on dotnet watch, but I think we might want to discuss this offline to ensure that we at least are not breaking the MTP-based dotnet test.

@Youssef1313 No, we are not ignoring --project completely. This makes sure it is not passed to the subcommand. dotnet watch still needs it internally.

Also, please look at #45761 as it seems like there is a catch22 here. If we don't fix it, we leave dotnet watch [subcommand] --project broken for most normal dotnet CLI scenarios.

What happens for Microsoft.Testing.Platform then? In that case I think it will need to be passed to test command, similar to run.

Yeah, that's the catch 22.

Looking over docs, it looks like dotnet test is the only command that has a difference in MCP. Is there a way to tell if we're running in the MCP environment? If so, we could add that as a condition here.

But, I dislike the additional brittleness that would add to the check. I'd prefer if we could query for the subcommand's acceptable arguments without running the subcommand. If there is a better way to query the acceptable args, please point them out for me. I'll change course to use that.

MCP is unrelated. MTP is "Microsoft.Testing.Platform" (so only relevant to test command - and is determined by global.json). I think you can just get the test command and look into its options. When you retrieve the test command, it will return the right thing depending on what is there in global.json.

Apologies, MCP is a typo. I meant MTP.

Alright, I think I'm in the right place.

Test's parser has GetCommand

sdk/src/Cli/dotnet/Commands/Test/TestCommandParser.cs

Line 176 in f099c19

public static Command GetCommand()

Even better to go one level up to dotnet's parser with GetBuiltInCommand

sdk/src/Cli/dotnet/Parser.cs

Line 189 in f099c19

public static Command GetBuiltInCommand(string commandName) =>

Then we'd be able to check any subcommand's arguments for pass-through viability.

fix(dotnet#45761): Stop passing arguments meant for dotnet-watch to a…

5026d2e

…ll commands

ronald-mz requested review from a team and tmat as code owners August 30, 2025 05:01

ronald-mz changed the title ~~fix(#45761): Stop passing arguments meant for dotnet-watch to all commands~~ fix(#45761): Stop forwarding dotnet-watch arguments to all commands Aug 30, 2025

ronald-mz changed the title ~~fix(#45761): Stop forwarding dotnet-watch arguments to all commands~~ fix(#45761): Stop forwarding dotnet-watch run arguments to all commands Aug 30, 2025

ronald-mz commented Aug 30, 2025

View reviewed changes

ronald-mz added 4 commits August 30, 2025 01:10

forgot to re-add the commands to root while tidying

9db77ff

remove tab

d16bf3c

Fix a brainfart that lead to a test case using a command as a launch-…

db68b03

…profile

[CombinatorialData]

d70c25a

build-analysis bot mentioned this pull request Aug 30, 2025

Template engine tests hitting known parallelism issue in GetVisualStudioInstances #44878

Open

tmat reviewed Sep 2, 2025

View reviewed changes

Youssef1313 reviewed Sep 12, 2025

View reviewed changes

Youssef1313 mentioned this pull request Nov 7, 2025

Previously working dotnet watch test command stopped working on .NET 9 #50776

Open

fix(#45761): Stop forwarding dotnet-watch run arguments to all commands #50558

Are you sure you want to change the base?

fix(#45761): Stop forwarding dotnet-watch run arguments to all commands #50558

Uh oh!

Conversation

ronald-mz commented Aug 30, 2025

Context

Watch CLI

Problem

Uh oh!

ronald-mz commented Aug 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Further Thoughts

Uh oh!

tmat Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmat Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ronald-mz Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ronald-mz Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tmat Sep 2, 2025 •

edited

Loading

tmat Sep 2, 2025 •

edited

Loading

ronald-mz Sep 12, 2025 •

edited

Loading

ronald-mz Sep 12, 2025 •

edited

Loading