`dotnet run file.cs` `#:` directive for project references

[ravindUwU]

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

The dotnet run file.cs document lists #: directives to specify the SDK, properties and NuGet package references of the implicit project file, but doesn't list a directive to reference a C# project.

Describe the solution you'd like

• A #:project directive (or equivalent) to reference a "full" C# project by its absolute/relative path, which translates to <ProjectReference Include="..." /> in the implicit project file.

• Maybe a #:reference directive to reference .DLLs in a similar way, which translates to <Reference Include="..." /> to my understanding? (although, I don't have any experience with this 😅).

Additional context

I think project references would be very useful to ship smol helper scripts alongside a main project?

e.g., a main ASP.NET Core web project Server/Server.csproj with Server/Program.cs and an EF Core DB context Server/Db.cs, and a scripts/firstRun.cs helper script which sets up the project for local development by creating an initial user, etc. using the DB context/services of the main project.

Program.cs would look roughly like,

namespace Server;

public class Program
{
	public static WebApplication Build(string[]? args = null)
	{
		var builder = WebApplication.CreateBuilder(args ?? []);
		builder.Services.AddDbContext<Db>();
		// Services configured here...
		return builder.Build();
	}

	public static void Main(string[] args)
	{
		var app = Build(args);
		// Request pipeline configured here.
		app.Run();
	}
}

...and the firstRun.cs helper script would look like,

#:project ../Server/Server.csproj

var server = Server.Program.Build();
using var scope = server.Services.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<>();

// ...

[wcrowther]

Project references (and .dll references) would take dotnet run file.cs to another level.

Here are a few examples where direct project references could be especially useful:

1. You maintain a personal code library you’d like to reuse easily across different projects from the command line.

2. You want to analyze a project—for example, to inspect its namespaces, classes, or other structural elements.

3. You want to generate code for a project —such as adapter classes — and need access to the models defined in the project

[wilka]

Also for teaching, I can provide a project to reference (and people can easily see the code if they want) without needing to make it a nuget package & deal with package sources.

[DamianEdwards]

Thanks for all the feedback on this. We're supportive of doing this but need to verify how much it complicates our plan for editor support in VS Code (it's complicated). If the work required to support this there is reasonable for the .NET 10 timeframe then we'll look to add support for #:project ../path/to/project/dir in .NET 10, otherwise we'll move this to .NET 11 for consideration.

Plan is we'd support both of the following:

• #:project ../path/to/project/dir
• #:project ../path/to/project/dir/ProjectFile.csproj

[ravindUwU]

If I had to write helper scripts that accompany a main project (as described in #48746 (comment)), I'd prefer to include them in a "Solution Folder" in the same Visual Studio Solution. Are there any plans to add running, debugging, etc. support for dotnet runnable C# files in Visual Studio?