Add support for dotnet file.cs (without explicit run subcommand)
#48387
Conversation
ghost
added
jjonescz
added
Area-run-file
|
Please make sure that Having a separate extension makes clear that it's the entry point and can be executed directly. Some people might even register |
|
I think this should also default to the Release configuration |
@alefranz yeah I think I agree with this |
|
@vrubleg |
There was a problem hiding this comment.
Pull Request Overview
Adds the ability to invoke a C# source file directly with dotnet file.cs, implicitly routing to dotnet run file.cs and defaulting to the Release configuration.
- Injects the
runsubcommand and-p:Configuration=Releasewhen the first argument is a.csfile. - Reorders property/configuration options so user-specified configurations override the default.
- Provides integration tests and updates documentation for the new
dotnet file.csshortcut.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Added an integration test for invoking dotnet file.cs with default and overridden configs. |
| test/dotnet-watch.Tests/CommandLineOptionsTests.cs | Updated expected ordering of property and framework build arguments in watch tests. |
| src/Cli/dotnet/Program.cs | Detects a .cs entry-point file and prepends run with Release configuration. |
| src/Cli/dotnet/Commands/Run/RunCommandParser.cs | Moved PropertyOption ahead of ConfigurationOption to let -c/--configuration override. |
| documentation/general/dotnet-run-file.md | Added description and shebang examples for the dotnet file.cs shortcut. |
Comments suppressed due to low confidence (2)
src/Cli/dotnet/Commands/Run/RunCommandParser.cs:82
- Fix typo in comment: change 'deafult' to 'default'.
// `-p:Configuration=Release` when `dotnet file.cs` is executed where we want the Release config to be deafult
src/Cli/dotnet/Program.cs:131
- Add unit tests covering
ProcessArgsbehavior for edge cases (e.g., uppercase extensions, absolute paths, non-existent files) to ensure the implicit run injection is robust.
? Parser.Instance.Parse(["run", "-p:Configuration=Release", .. args])
| @@ -64,6 +64,9 @@ For example, the remaining command-line arguments after the first argument (the | |||
| (except for the arguments recognized by `dotnet run` unless they are after the `--` separator) | |||
| and working directory is not changed (e.g., `cd /x/ && dotnet run /y/file.cs` runs the program in directory `/x/`). | |||
|
|
|||
| `dotnet path.cs` is a shortcut for `dotnet run -p:Configuration=Release path.cs` provided that `path.cs` exists and has `.cs` file extension. | |||
| Because of the `-p:Configuration=Release` option, `dotnet path.cs` builds and runs the program with Release configuration by default unlike `dotnet run path.cs`. | |||
There was a problem hiding this comment.
#49202 (comment) indicates that #!/usr/bin/env dotnet is the only supported way to run via shebang. So do we want to couple these decisions together? If user wants to run their script as ./myapp.cs, they need to run in release mode?
It looks like when the program contains #:property Configuration=Debug, dotnet app.cs will respect that. So that might be reasonable. Though, I think that is also different than passing -p:Configuration=Release for a dotnet build, I thought that a property value on command line normally "wins" over options in the project file. I might have that wrong. If there is a difference there it would be good to document it.
There was a problem hiding this comment.
I thought that a property value on command line normally "wins" over options in the project file.
That's correct and it's what happens, I will add a test.
There was a problem hiding this comment.
So do we want to couple these decisions together? If user wants to run their script as
./myapp.cs, they need to run in release mode?
Good question. @DamianEdwards? I wouldn't be against removing the implicit -c Release as (1) it might be confusing that it behaves differently from dotnet run, (2) users can add #:property Configuration Release to their scripts to achieve the behavior, (3) as Rikki discovered, it's impossible to overwrite the configuration with argumentless executable.
There was a problem hiding this comment.
Yep that's fair. This is kinda a philosophical question. If all this maps to dotnet run then the default configuration should be Debug. To change it, folks can use a property directive, implicit build file, or environment variable, all of which should work even in the shebang single argument case.
Let's keep it all aligned as Configuration=Debug.
There was a problem hiding this comment.
Maybe it makes sense to make dotnet run always use Release by default no matter what kind of project it runs? It sounds like the most desirable default in this case. If somebody needs to run with Debug config for some reason, a new command dotnet debug could be introduced, which would be equal to dotnet run with the only difference that it uses Debug configuration by default. Or a short argument --debug for the dotnet run would also be fine and easy to remember. The -p:Configuration=Debug or -p:Configuration=Release are too long and inconvenient for something that you are supposed to quickly type and execute in command line.
There was a problem hiding this comment.
The
-p:Configuration=Debugor-p:Configuration=Releaseare too long and inconvenient for something that you are supposed to quickly type and execute in command line.
There are shorter versions: -c Debug and -c Release
There was a problem hiding this comment.
you made me dream for a second 🥲 I still believe that by default it should be "fast" for this scenario.
It's fair to not conflate it with this PR, but I think it would be worth to reconsider it before the single file support is shipped.
There was a problem hiding this comment.
There's almost no chance of us changing the default configuration for dotnet run as it's been Debug forever and impacts so many experiences in the developer inner-loop (but of course just saying that out load means it's more likely to happen lol). I don't believe debug vs. configuration changes compile and startup time significantly enough for it to be of concern WRT single file app launch time. The far bigger factors are cold-start time of MSBuild and MSBuild operations themselves (aka building) for which we have intend to do other work. For throughput/execution performance it's true that debug vs. release can make a large difference but not for the scenarios we primarily envisage run-file to be used for, and in the cases where it really does matter for a specific app, it's easy enough to add the directive to the file or pass the -c Release command line argument.
|
@MiYanni for a review, thanks |
Resolves #49202.