Idea: Support "dotnet run"ning single source files without a project file.

[teo-tsirpanis]

When released, the .NET Core CLI tools made .NET development significantly easier with the command line. All it needs for a .NET Core app to run is a typically small .*proj file and the source files next to it.

However, for very small programs (such as code for educational purposes or one-off scripts) whose project file is the same unremarkable one, it is a source of redundancy, especially when there are many source files on the same directory.

For this reason, and to emulate the behavior of tools like python and node with their respective languages, I am proposing to make commands like dotnet run MyFile.cs compile and run a single-source-file app.

This change will give a LINQPad-like feature to the .NET Core SDK and will make the .NET languages significantly more accessible and even enable them to be used like scripting languages.

Some other details I have thought:

• A command like dotnet run MyFile.cs will behave like creating a project file like this:

  <Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
      <Language>C#</Language>
      <TargetFramework>net5.0</TargetFramework>
      <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
      <OutputType>Exe</OutputType>
    </PropertyGroup>
    <ItemGroup>
      <Compile Include="MyFile.cs"/>
    </ItemGroup>
  </Project>
  

  and then running dotnet run on this. I intentionally included the Language element because the project file might not necessarily need to be stored on disk for its language to be determined by its extension.

• The source file will have to be explicitly specified, even if only one source file exists in the current directory.

• dotnet running a source file will work with any .NET Language (C#/VB/F#). It will not deprecate tools like F# Interactive, because it will not be interactive in the REPL sense of the term and because it will compile the sources first, instead of interpreting them.

• dotnet running a source file will not support more than one source files.

• dotnet running a source file will not support custom NuGet packages. Languages like F# that get their source library from NuGet will behave as if no specific PackageReference for that library was included.

• Like the actual dotnet run, the framework could be customized with the --framework option and will default to the latest .NET (Core) version of the current SDK (after taking global.json into consideration).

• dotnet running a source file will support running in either Release or Debug mode (and even allow attaching a debugger).

  In a divergence from the norm, we could default to Release mode here, for better performance.

• dotnet running a source file will only support console apps. Libraries have no entry point and GUI apps typically need more than one file. CLI arguments will be passed after double dashes as usual.

• dotnet running a source file will leave no trace in the file's directory. The compiled assembly will be cached somewhere else. Successive dotnet runs of the same source file with the same settings will not need a recompilation.

• dotnet running a source file will not be extended to commands like dotnet build or dotnet publish

[WeihanLi]

I'm trying on this project(https://github.com/WeihanLi/dotnet-exec) to execute code directly without a project file, it would be great and simple to run without a project file

[kant2002]

I think this is closely related to the https://github.com/dotnet/fsharp/issues/13341 where people like to have FSX files to be compiled down to exe files. Currently dotnet SDK assumes that every executable target has project file, but for scripting environments that's not true. Great that some interest was shown in https://github.com/dotnet/designs/pull/213, but seems to be initiative to move this forward does not materialized yet

[Untersander]

dotnet-repl which is based on dotnet-interactive achieves a similar thing, it also allows to execute C# and F# files.