Support build/restore of file-based programs #48662

jjonescz · 2025-04-23T11:31:20Z

Resolves #48551.

Copilot

Pull Request Overview

This PR adds support for building and restoring file‐based programs by introducing new virtual commands and updating argument names across various commands. Key changes include:

Replacing the old SlnOrProjectArgument with SlnOrProjectOrFileArgument.
Introducing VirtualProjectBuildingCommand and related virtual command types for file-based program processing.
Updating documentation to reflect support for file-based commands.

Reviewed Changes

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

Show a summary per file

File	Description
src/Cli/dotnet/Commands/Workload/Restore/WorkloadRestoreCommandParser.cs	Updated argument usage for workload restore.
src/Cli/dotnet/Commands/Workload/Restore/WorkloadRestoreCommand.cs	Adjusted argument references for restore commands.
src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs	Introduced virtual command logic for file-based runs.
src/Cli/dotnet/Commands/Run/RunCommand.cs	Refactored virtual command creation.
src/Cli/dotnet/Commands/Restore/RestoringCommand.cs	Updated restore command type to ForwardingRestoreCommand.
src/Cli/dotnet/Commands/Restore/RestoreCommandParser.cs	Updated argument naming and restore command creation.
src/Cli/dotnet/Commands/Restore/RestoreCommand.cs	Converted RestoreCommand to an abstract class with concrete implementations.
src/Cli/dotnet/Commands/Build/BuildCommandParser.cs & BuildCommand.cs	Updated argument names and introduced virtual and forwarding build commands.
documentation/general/dotnet-run-file.md	Updated documentation to include file-based command support.

Files not reviewed (10)

src/Cli/dotnet/CliStrings.resx: Language not supported
src/Cli/dotnet/xlf/CliStrings.cs.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.de.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.es.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.fr.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.it.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.ja.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.ko.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.pl.xlf: Language not supported
src/Cli/dotnet/xlf/CliStrings.pt-BR.xlf: Language not supported

src/Cli/dotnet/Commands/Build/BuildCommand.cs

jasonmalinowski

Signing off that I've reviewed it, but not sure my signoff means much. I'm can't speak if any of the introduction of virtual command objects is the right pattern to do or not.

jasonmalinowski · 2025-04-23T21:52:00Z

src/Cli/dotnet/Commands/Restore/RestoreCommand.cs

+        string[] forwardedOptions = result.OptionValuesToBeForwarded(RestoreCommandParser.GetCommand()).ToArray();

-        msbuildArgs.AddRange(result.GetValue(RestoreCommandParser.SlnOrProjectArgument) ?? []);
+        if (fileArgument is [{ } arg] && VirtualProjectBuildingCommand.IsValidEntryPointPath(arg))


Suggested change

if (fileArgument is [{ } arg] && VirtualProjectBuildingCommand.IsValidEntryPointPath(arg))

if (fileArgument is [{ } arg] && VirtualProjectCommandHelpers.IsValidEntryPointPath(arg))

Or move that to some other similarly-named type?

I'm planning to rename that to something like FileBasedProgramHelpers to match the API that will be extracted out of it into Roslyn (dotnet/roslyn#78159). I'd rather do that in a separate PR to avoid large diffs (if Git wouldn't recognize it as a rename)

jasonmalinowski · 2025-04-23T22:02:34Z

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

                var restoreRequest = new BuildRequestData(
                    CreateProjectInstance(projectCollection, addGlobalProperties: static (globalProperties) =>


Not new in this PR, but if there's now a restore command directly, is there some way to share this logic that's setting the environment? Otherwise it seems we risk a change to dotnet restore RealProject.csproj not being updated here?

That's currently not possible. The real project-based restore calls msbuild.exe where this logic lives internally. Here we need to call msbuild API where the logic is not exposed. There is a tracking issue linked in the comment above to publish an API for that.

jjonescz · 2025-04-28T08:39:59Z

@RikkiGibson @chsienki @MiYanni for reviews, thanks

src/Cli/dotnet/Commands/Build/BuildCommand.cs

chsienki · 2025-04-28T17:22:23Z

src/Cli/dotnet/Commands/Restore/RestoreCommand.cs

+
+public sealed class ForwardingRestoreCommand : RestoreCommand
+{
+    public ForwardingRestoreCommand(IEnumerable<string> msbuildArgs, string msbuildPath = null)


I suspect I'm missing something, but I don't fully understand why we need to wrap the MSBuildForwardingApp in a command. I assume the type hierarchy requires it, but it seems like it should be possible to just have an 'executable command' or something that implements Execute and then we wouldn't need as many type wrappers?

Yes, with some refactoring we can do that, let me try it. Thanks.

MiYanni

Seems like a fine way to do this. There's likely a cleaner way, but would require more code changes, and I have no concrete suggestion currently. Just something for me to keep in mind going forward.

richlander · 2025-08-12T21:14:16Z

I'm using P7. I ran dotnet build app.cs. It is not clear to me where the binaries were placed. It is very clear with dotnet publish app.cs.

RikkiGibson · 2025-08-12T21:43:41Z

In preview 7 I get the following behavior

$ dotnet build lab.cs
Restore complete (1.5s)
    info NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  lab succeeded (3.1s) → C:\Users\rigibson\AppData\Local\Temp\dotnet\runfile\lab-0fb3717a190af7b4e76d8da55b826c4258b79d16fc37de65387781aefc3e7366\bin\debug\lab.dll

Build succeeded in 6.0s
$ dotnet --version
10.0.100-preview.7.25366.104

Do you have any env vars/profile settings that are customizing the msbuild logging in any way?

richlander · 2025-08-12T22:17:45Z

rich@richs-MacBook-Pro test-file-based-apps % cat app.cs 
Console.WriteLine("Hello World!");% 
rich@richs-MacBook-Pro test-file-based-apps % dotnet build app.cs 
rich@richs-MacBook-Pro test-file-based-apps % ls
app.cs
rich@richs-MacBook-Pro test-file-based-apps % dotnet --version
10.0.100-preview.7.25380.108
rich@richs-MacBook-Pro test-file-based-apps % export | grep DOTNET
rich@richs-MacBook-Pro test-file-based-apps % uname -a
Darwin richs-MacBook-Pro.local 25.0.0 Darwin Kernel Version 25.0.0: Fri Jul 25 23:19:02 PDT 2025; root:xnu-12377.0.187.0.2~21/RELEASE_ARM64_T6041 arm64

I see the dotnet build output, but it flashes by quickly, only ever one line visible at a time.

As you can likely guess from uname -a, I'm on macOS 26/Tahoe.

richlander · 2025-08-12T22:20:48Z

I'm more than happy to file a separate issue. No need to re-use this PR. Just seemed like the place to start.

RikkiGibson · 2025-08-12T22:26:36Z

If the issue also occurs for ordinary projects I would file an issue on msbuild as it's likely their logger misbehaving, if it only occurs for file-based apps then would file it in this repo.

richlander · 2025-08-12T22:41:48Z

Specific to FBA. Will file an issue here.

richlander · 2025-08-12T22:45:52Z

#50227

Support build/restore of file-based programs

193ae4d

jjonescz added the Area-run-file Items related to the "dotnet run <file>" effort label Apr 23, 2025

jjonescz requested a review from a team April 23, 2025 11:31

Update a test

ef34485

jjonescz marked this pull request as ready for review April 23, 2025 14:06

Copilot AI review requested due to automatic review settings April 23, 2025 14:06

Copilot AI reviewed Apr 23, 2025

View reviewed changes

src/Cli/dotnet/Commands/Build/BuildCommand.cs Outdated Show resolved Hide resolved

jasonmalinowski approved these changes Apr 23, 2025

View reviewed changes

Test build command

f863639

RikkiGibson self-assigned this Apr 24, 2025

jjonescz requested a review from a team April 25, 2025 11:59

jaredpar approved these changes Apr 28, 2025

View reviewed changes

chsienki approved these changes Apr 28, 2025

View reviewed changes

Remove type wrappers

e60ccb7

jjonescz requested a review from MiYanni April 29, 2025 15:42

MiYanni approved these changes Apr 29, 2025

View reviewed changes

jjonescz merged commit f98b22c into dotnet:main Apr 30, 2025
30 checks passed

jjonescz deleted the sprint-build branch April 30, 2025 08:49

jjonescz mentioned this pull request Jun 9, 2025

dotnet build should also support cs files #49299

Closed

richlander mentioned this pull request Aug 12, 2025

dotnet build app.cs should produce artifacts in the current directory #50227

Open

	if (fileArgument is [{ } arg] && VirtualProjectBuildingCommand.IsValidEntryPointPath(arg))
	if (fileArgument is [{ } arg] && VirtualProjectCommandHelpers.IsValidEntryPointPath(arg))

		var restoreRequest = new BuildRequestData(
		CreateProjectInstance(projectCollection, addGlobalProperties: static (globalProperties) =>

Support build/restore of file-based programs #48662

Support build/restore of file-based programs #48662

Uh oh!

Conversation

jjonescz commented Apr 23, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

jasonmalinowski left a comment

Choose a reason for hiding this comment

Uh oh!

jasonmalinowski Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

jjonescz Apr 24, 2025

Choose a reason for hiding this comment

Uh oh!

jasonmalinowski Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

jjonescz Apr 24, 2025

Choose a reason for hiding this comment

Uh oh!

jjonescz commented Apr 28, 2025

Uh oh!

Uh oh!

chsienki Apr 28, 2025

Choose a reason for hiding this comment

Uh oh!

jjonescz Apr 29, 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!

MiYanni left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

richlander commented Aug 12, 2025

Uh oh!

RikkiGibson commented Aug 12, 2025

Uh oh!

richlander commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

richlander commented Aug 12, 2025

Uh oh!

RikkiGibson commented Aug 12, 2025

Uh oh!

richlander commented Aug 12, 2025

Uh oh!

richlander commented Aug 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jjonescz Apr 29, 2025 •

edited

Loading

richlander commented Aug 12, 2025 •

edited

Loading