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

[richlander]

This is what happens:

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 on a single line and then that line becomes the next command prompt. There are no artifacts in my app directory.

Repro on macOS 26 and Ubuntu 24.04

[richlander]

Related:

• Support build/restore of file-based programs #48662

[jjonescz]

The problem is that default verbosity of file-based commands is quiet whereas project-based commands have default verbosity minimal. I will fix that inconsistency. You could work around it by setting the verbosity explicitly, e.g., dotnet build app.cs -v:m.

[richlander]

I think the implementation is conflating what we want for the fancy run experience with generating persistent artifacts.

This isn't what I had in mind:

rich@richs-MacBook-Pro test-file-based-apps % dotnet build app.cs -v:m
Restore complete (0.2s)
    info NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  app succeeded (0.1s) → /Users/rich/Library/Application Support/dotnet/runfile/app-8816e08be98281f19d9ca74ffd698a4be598a4700bd20daaa1b6ee9dd6379138/bin/debug/app.dll

Build succeeded in 1.0s
rich@richs-MacBook-Pro test-file-based-apps % find .
.
./app.cs

I was wanting something much closer to:

rich@richs-MacBook-Pro test-file-based-apps % dotnet publish app.cs 
rich@richs-MacBook-Pro test-file-based-apps % find .
.
./artifacts
./artifacts/app
./artifacts/app/app
./artifacts/app/app.dSYM
./artifacts/app/app.dSYM/Contents
./artifacts/app/app.dSYM/Contents/Resources
./artifacts/app/app.dSYM/Contents/Resources/Relocations
./artifacts/app/app.dSYM/Contents/Resources/Relocations/aarch64
./artifacts/app/app.dSYM/Contents/Resources/Relocations/aarch64/app.yml
./artifacts/app/app.dSYM/Contents/Resources/DWARF
./artifacts/app/app.dSYM/Contents/Resources/DWARF/app
./artifacts/app/app.dSYM/Contents/Info.plist
./app.cs

[jjonescz]

Thanks for clarifying. We still want to fix the output verbosity inconsistency. And where to put build output artifacts is a separate question. The current design was chosen intentionally (cc @DamianEdwards). It's in fact not expected that users would do dotnet build app.cs (the command might not be even supported if IDEs didn't need it). The default experience is dotnet run app.cs - and for that we don't wont to "pollute" the source directory with build artifacts. Can you elaborate why you want to see build outputs of file-based apps? Would some --output switch be useful to you? FWIW, something like -p:ArtifactsPath=./artifacts should work even today; see also #49568.

[richlander]

I grasp and appreciate the design per run.

The approach basically says: "run and publish are supported verbs and build has been deleted for file-based apps". Is that the intent?

On the other hand, publish seems to be intended because NAOT appears to be the default.

I was wanting to use this app project style as a replacement for bash scripts, but where I can run them with time when needed. I was intended to use build -c Release to create a binary because I didn't want to go down the NAOT path for tht use case.

My true use case is "Get LLMs to create low-complexity .NET tools for executing on my goals." I was hoping that file-based apps could be a big part of that. So far, not.

[jjonescz]

The approach basically says: "run and publish are supported verbs and build has been deleted for file-based apps". Is that the intent?

Yes, that was the intent. File-based apps are definitely supposed to be less capable than project-based apps. And so far we didn't have motivating scenarios for build.

but where I can run them with time when needed.

Okay, that's interesting. You can use dotnet run --no-build for that. And it also sounds like dotnet build --output ./artifacts (when implemented) would work for your scenario. (And you can use dotnet build -p:ArtifactsPath=./artifacts or even #:property ArtifactsPath=./artifacts in the meantime.)

I was hoping that file-based apps could be a big part of that. So far, not.

Why not? Only because of the build outputs being hidden in a temp directory by default?

[richlander]

I want a flexible project type that I can use as either script style or binary executable style. When I'm using code assistants, it's very iterative so I don't want to use NAOT as the default.

I typically have three tiers:

• Run the script to get something done (like a set of JSON files to match a schema update)
• Time the app to understand how long something takes (Running a tool over 100 vs 1000 files)
• Integrate a stable tool into a workflow (build as NAOT and link into a _tools directory that scripts can rely on)

So far, file-based apps don't work well in that paradigm. I'm not going to teach LLMs to flip the PublishAOT property to make that work. I'm happy to pivot between build and publish.