Add basic support for 'dotnet run file.cs'

[jjonescz]

Spec: #47020 (rendered markdown)

[Copilot]

Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/Cli/dotnet/commands/dotnet-run/RunCommand.cs:609

• [nitpick] The method 'DiscoverProjectFilePath' now returns both a project file path and an entry point file via an out parameter; consider renaming it (for example, to 'DiscoverProjectAndEntryPointPaths') to better reflect its dual purpose.

private static string? DiscoverProjectFilePath(string? projectFileOrDirectoryPath, ref string[] args, out string? entryPointFilePath)

src/Cli/dotnet/commands/dotnet-run/RunCommand.cs:250

• [nitpick] Consider renaming the 'projectFactory' out parameter to 'projectInstanceFactory' for improved clarity since it is intended to supply a ProjectInstance.

private void EnsureProjectIsBuilt(out Func<ProjectCollection, ProjectInstance>? projectFactory)

[jjonescz]

@MiYanni @RikkiGibson @chsienki for reviews, thanks

[hez2010]

I believe the most usage would be scripting with shebang syntax. Should we run it with Release config by default to avoid unnecessary by-default slow down?

[jjonescz]

I believe the most usage would be scripting with shebang syntax. Should we run it with Release config by default to avoid unnecessary by-default slow down?

I would rather not change any defaults to avoid confusion. However, if you are using shebang, presumably you will specify the Release config there:

#!/usr/bin/dotnet run -c Release

[Forgind]

I heard offline that the new plan is to have it just build/execute one file instead of globbing everything in the current directory and subdirectories. That's my last serious concern right now, so I'm happy signing off preemptively 🙂 Thanks for all your work on this! I think it's a fantastic improvement in the new user experience

[jjonescz]

In theory, we could remove this restriction now and let the compiler report errors if an entrypoint is missing in the compilation (consisting of the sole input file). However, if we decide to add the support for multiple files back, we will likely want this restriction again. So, I think it's better to keep the restriction (to avoid a breaking change later) and relax it in the future if necessary.

[Forgind]

I'd personally be mildly in favor of removing it mostly because I think top level statements were a bad idea in the first place. (I'm not sure how to do this, but a different check that verifies that there is an entrypoint in this file would be perfect in my view.) On the other hand, I do think your logic is sound, so I think it's ok to keep this.

[jjonescz]

@MiYanni @Forgind @chsienki @RikkiGibson. I've updated this PR to limit to single file instead of globbing. Please take a look if you want, I'd like to merge if there are no objections and follow up with other PRs (like grow up command and #package directive). Thanks.

[Forgind]

No objections—thanks for your work on this!

[Forgind]

I'd personally be mildly in favor of removing it mostly because I think top level statements were a bad idea in the first place. (I'm not sure how to do this, but a different check that verifies that there is an entrypoint in this file would be perfect in my view.) On the other hand, I do think your logic is sound, so I think it's ok to keep this.