You were already using F#'s syntax for C# NuGet references in .NET Interactive. Even NuGet itself labels this syntax "Script & Interactive" in its picker.
.NET interactive uses a dialect of C# - the script dialect. With file based apps, we strive to use the standard C#, so you can convert file based apps to full projects at any time.
That doesn't explain why standard C# had to deviate further from the script dialect just for import directives. These directives don't interfere with the rest of the grammar.
Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!) Has there been any effort to have the rest of .NET adopt this new syntax or share concerns?
On that note, is any language other than C# supported for `dotnet run`? Is the machinery at least documented for other MSBuild SDKs to use? Considering how dotnet watch keeps breaking for F#, I suspect not.
> Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!)
Yes, we believe so. There is not much to be gained from reusing the syntax (it's not like you can import cs from csx or vice versa). We are also adding other directives, e.g., `#:property` - it would not make sense to reuse `#r` for that. `#r` is short for "reference", because it was originally meant for referencing DLLs which is discouraged in modern .NET. The main motivation for file-based programs is to lower the entry barrier, and having opaquely named directives like `#r` seems counter-productive.
> On that note, is any language other than C# supported for `dotnet run`?
> Is the machinery at least documented for other MSBuild SDKs to use?
There is really not much special machinery, an in-memory csproj file is created and built via MSBuild just like an on-disk csproj would. Any MSBuild SDK can be used via the `#:sdk` directive.
>referencing DLLs which is discouraged in modern .NET
You can't do much of anything in .NET without referencing Nuget assemblies.
> opaquely named directives like `#r` seems counter-productive
Then why is it the existing standard?
Agreeing with others, '#r "nuget:' should at least be an option.
And otherwise (but I guess regarless if you stick with this syntax) you will have to add another tab to Nuget called "dotnet run". "Script & Interactive" is already present in Nuget and shows the #r syntax for a reference.
> You can't do much of anything in .NET without referencing Nuget assemblies.
And referencing NuGet assemblies is of course supported via the #:package directive. It's just that referencing DLLs directly is not a common scenario, hence it's not supported for now (but can be added later).
> Agreeing with others, '#r "nuget:' should at least be an option.
> And otherwise (but I guess regarless if you stick with this syntax) you will have to add another tab to Nuget called "dotnet run". "Script & Interactive" is already present in Nuget and shows the #r syntax for a reference.
Agree but also note that the ".NET CLI" tab which tells you to run "dotnet add package" should also work in near future, see https://github.com/dotnet/sdk/issues/49200.
> we don't want to create a new C# scripting dialect hence it isn't possible to "import" other files (that's not how C# works)
This statement is a bit confusing. From a user perspective, "dotnet run" does add a new scripting dialect. I would like to rewrite all my csx utilities to use this.
I've been using dotnet-script for several years for both unit testing code and for creating small utilities. Being able to load scripts (with "#load - see below) from other scripts is a core feature for keeping my code DRY. It would be a knock against "dotnet run" if a comparable syntax was not available. It's just a preprocessor - not a change to the C# syntax. Just like the other '#:' preprocessors being added.