[Feature] Proposing an option to include other C# source files for `dotnet run app.cs`

[egvijayanand]

Is your feature request related to a problem? Please describe.

I would suggest adding another directive along with the sdk, property, and package to reference other C# source files as mentioned below.

The proposed #:include directive would add multiple C# source files to the compilation unit.

The file provided as a parameter to the dotnet run command would be the entry point, and other files are supporting files.

Describe the solution you'd like

The source file path can be mentioned as an absolute path or a relative path to the entry file.

#:include Foo.cs

// Other statements

Additional context

dotnet run app.cs CLI experience

[KalleOlaviNiemitalo]

I'd rather call it #:compile, to match the MSBuild Compile item type and to better distinguish it from textual inclusion like #include in the C preprocessor.

[egvijayanand]

compile is too technical, and a newbie might get confused.

If not include, then load might be an option as used by LINQPad.

[DamianEdwards]

Various approaches to multi-file support are being discussed in #47672

[dcuccia]

@DamianEdwards I can't tell if the #47672 discussion includes script entry points which could reference other projects, e.g. a "#:project" app directive. Not sure if this should be it's own item (or is a duplicate), but love the direction here and really want the ability to reference other .csproj libraries in the same modality I'd reference other nuget packages. My use case is tons of measurement or analysis script "lab apps" or cron jobs that call into a well-factored solution - usually in the same repo, but it shouldn't have to be.

Our typical workflow is a little awkward, and I think this could really help streamline things. Currently we:

0. Create Unit/Integration tests around our well-factored .NET API (of course :))
1. Create a Lab App 1 csproj with top-level statements to run through a task that exercises our "standard" .NET code base (with multiple projects). This is one step removed from the tests - we're focused on completing a specific business task. BUT, it's often a great place for discovering edge cases, and the ability to "step into" the codebase is fantastic. Discovered issues often get promoted to new unit tests. Once this is working well, we...
2. Create a .NET Polyglot Notebook with the same copy-pasted code, but with additional in-line documentation, ready to share with others. For us, the visualization of intermediate assets are another plus of Notebooks, but that's not a big deal for this conversation IMO.
3. Create a second Lab App 2 for a slightly different purpose, because we don't want Lab App 1 to get out of control, and rinse and repeat into a Notebook. Then we used to group these lab apps in a "solution folder" so they wouldn't mess up visualization of the project. But since C# Dev Kit doesn't support solution folders (yet, at least), we usually...
4. Combine the two scripts into a single project, and consider using SmallSharp for multiple entry points, but then realize (again) that C# Dev Kit doesn't support this. We could set up launch.json profiles to run the different entry points, but that's a lot to maintain, so we just default to a command-line parameter to switch between the different tasks. If we get fancy, we'll use static abstract contracts for the script classes and auto-discover them and launch input parameters by registering and matching strings.
5. Lab App count grows and we suffer from Notebooks always being out of sync. Fixing a bug means fixing things in multiple places, and often a team member finds and fixes a bug or adds an enhancement directly in the Notebook without fixing the Lab App and then we have a zombie Lab App. Debugging Notebooks directly isn't a first-class developer experience (you have to attach the debugger to the Notebook), but we realize maybe we should have gone with Notebooks as a single source of truth in the first place because this is out of hand. Or used CS-Script.

A little dramatic, but hopefully the churn comes through. If we could #:project "..\Contoso\Contoso.Api", and dotnet run any .cs file in a folder without "graduating" via conversion to a traditional project, we could have one, first-class debuggable source of truth AND lightweight scripts that get shipped/packaged either alongside our api, or separately. Maybe someday a) the Notebooks team builds off this story and allows code interleaving/sharing with the scripts, and/or b) the .NET team allows collapsible/hidable markdown comments inside the .cs file w/o losing all the great Dev Kit tooling. A dev can have dreams, right?

Please let me know if I should promote this to its own issue, and/or if it would be helpful to create some samples to flush this out this concept.

[DamianEdwards]

@dcuccia this can be achieved already via our support for implicit build files, i.e. Directory.Build.targets. I have an example of this here.

That said, ability to reference a project is tracked by #48746

[dcuccia]

@dcuccia this can be achieved already via our support for implicit build files, i.e. Directory.Build.targets. I have an example of this here.

That said, ability to reference a project is tracked by #48746

@DamianEdwards fabulous on both counts! Thank you.