Support publishing file-based apps

[DamianEdwards]

File-based apps are currently supported by the dotnet run, dotnet restore, and dotnet build commands. We should consider supporting them with dotnet publish so that ready-to-deploy assets can be easily produced by file-based apps.

This was asked on the socials: https://bsky.app/profile/normj.bsky.social/post/3lqb44uqms225

If we do consider this, we should strongly consider changing the defaults compared to project-based apps given this is a wholly new scenario and we get to decide a new default experience without needing to consider breaking changes (as long as they map to the project equivalent when dotnet project convert is run), e.g.:

• Default to self-contained publish
• Default to single-file publish
• Defaulting to trimmed or native AOT is likely far too limiting given the current state of the ecosystem but these can be opted into easily with the property directive, i.e. #:property PublishAot true

Doing this would make creating native AOT command line utils from C# extremely simple, requiring only a single .cs file with the #:property PublishAot true directive, and execution of dotnet publish app.cs.

[normj]

My thoughts when asking about this is AWS Lambda functions are often small micro services that could be a single file with referenced NuGet packages. The single file experience which would require dotnet publish could be a nice light weight experience for those simple functions.

[DustinKingen]

Another vote for native AOT for functions.

[DamianEdwards]

Defaulting to trimmed or native AOT is likely far too limiting given the current state of the ecosystem but these can be opted into easily with the property directive, i.e. #:property PublishAot true

I'm considering changing my stance to be more bold on this now and say in this new world of file-based apps we could default them to publish native AOT. Be the change you want to see and all that. We likely won't get another chance to change a default like this for a very long time.

[agocke]

I'm supportive of the change to Native AOT by default. More stuff is becoming compatible every day. It's also easy to disable if needed.

One area that I think could help is dotnet/runtime#116280. Thus far the sticking point for most people is having to use JSON source generation instead of reflection, and the fact that the API is different for source generation. Fixing those problems would make this an even smoother transition. The alternative is to use an AOT-first library like https://github.com/serdedotnet/serde, but many people (understandably) will want to use FX built-ins instead.