I'm interested. Please ping me in the future if you need testers or any kind of help.

These are my 2 cents on this:

• Support this only if all of the files are *.csx.
• All *.csx files in the same directory as well as any nested directories are assumed to be in the same compilation at runtime in dotnet run.
• dotnet run will fallback to this only if:
  • directory does not have any csproj files.
  • no project.json files.
  • no bin or obj folders and no binary files that can be ran in the folder or any recursive directories under it (no .NET *.exe's, *.dll's).
    • if one is found, only the one that has the +x bit set is ran, on Windows it looks for the apphost (*.exe) and use's it's file name to obtain the name for the *.dll that the *.exe would normally run anyways.
• #r reference not needed to reference other *.csx files, dotnet run would need a special way to support this one though.
• #r "nuget:PackageId" is only required in a single *.csx file, after that it is usable in all of them.
• The user can also add an GlobalUsings.csx file for any and all global usings they want to use for the entire thing, however it must be all done by hand and not by any special tooling.
• the primary csx file that defines the start of the program must be named main.csx. This is to only support top level applications and top level code must be in that file. Also this file must be in the EXACT folder for which dotnet run is invoked from.
• the application will only run with the absolute newest version of the runtime installed on the user's system. This includes the latest patch of the newest major version they have installed to avoid security issues. Also implies the newest C# language version as well that the .NET SDK supports.
• For the frameworks required a new file is required as well for this layout: frameworks.json which lists the frameworks required at runtime:
  • Can also work with the frameworks from workloads such as maui for example as well.
  • Example:

{
    "frameworks": [
        "Microsoft.WindowsDesktop.App",
        "Microsoft.NETCore.App",
    ]
}

Notes:

• After dotnet run builds the code it then stores the built code in a *.dll (file name is the name of the folder from which dotnet run is invoked in) to cache for future runs unless --rebuild is specified.
• Built code is built with Ready to Run and crossgen2'd for max optimizations.

With all of this I think it would be a good compromise for easier ways of running .NET Program code in a way that is similar in nature to python, JavaScript, etc.

Overall I think the document can be summarized down to basically what I wrote above which I feel is much better and also easier to understand and break into parts for people to handle.

I just thought of this as well but an alternative to using the #r "nuget:PackageId" preprocessor on csx files:

• a packages.json that defines the nuget packages required to build and run the scripts, along with the versions (dotnet run would convert this to the equivalent #r preprocessor for it as well expanded with the version of it too).
  • this has a benefit as well of being able to explicitly specify a specific version as well which for some might be a good idea as well.

After thinking about this more, the processing of this for dotnet run could be made on the MSBuild side in the Build target for when they use only csx + frameworks.json + packages.json files (no cs, csproj, sln, and no project.json).

And due to dotnet run invoking an implicit build by default, that means a binary would be cached that it can then run.

Support this only if all of the files are *.csx.

Hoping for *.cs file also

All *.csx files in the same directory as well as any nested directories are assumed to be in the same compilation at runtime in dotnet run

I think this could be considered as an option, like enabling default items or not in the MS Build

And I'm trying on the dotnet-exec project, trying to make it possible to simpler C# programs, while maybe not in the correct way.

Closed since .NET SDK is implementing the dotnet run file feature, which is ready to play since .NET 10 SDK Preview 4, see detail on
https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md

Hopefully, there's a detailed design document for it, created a ticket for it
dotnet/sdk#49157