https://ttu.github.io/dotnet-script/
Or that they on the wisdom of the C# Language Runtime, decided on an incompatible approach to how F# references dependencies on its scripts.
https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp...
They do acknowledge it and other efforts:
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
Unless you plan to also support the same approach on VB and F# scripts.
I dread the moment C# introduces sum types (long overdue) and then have them incompatible with F#. On a general note, the total disregard towards F# is very much undeserved. It is far superior to the likes of Python, and would easily be the best in the areas of machine learning and scripting, but apparently nobody inside MS is that visionary.
The fact that Python is the language of choice for ML makes it clear that technical superiority was not necessary or relevant. Python is the worst language around. The lack of better languages was never the problem. Making F# technically better wasn't going to make it the choice for ML.
This is why I always mention, when .NET team complains about adoption among new generations not going as desired they should look into their own employer first.
> they should look into their own employer first.
Why people still beat the dead horse of Python (performance) is beyond me.
You say that importing other files is not how c# works, but I think that's not entirely true. If you now treat a file as a project then an import is pretty much a project reference just to a .cs file instead of a .csproj file.
So I'd love to see something like that working: #:reference ./Tools.cs
Which should be the same as a ProjectReference in csproj or for a "real" project something like this: #:reference ./Tools/Tools.csproj
That would also enable things like this in a csproj file: <ProjectReference Include="..\Tools\Helpers.cs" />
E.g. let's say I have a compiled app and I just want to reach inside of it and invoke some method.
https://github.com/dotnet/interactive/blob/main/docs/nuget-o...
Now you've created a new dialect.
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.
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`?
File-based programs are for C# only. F# already has `dotnet fsi`. VB support seems unlikely per the language strategy: https://learn.microsoft.com/en-us/dotnet/fundamentals/langua...
> 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.
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.
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.
Thanks, we hear you and plan to add support for it, see https://github.com/dotnet/sdk/issues/49199
> 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.
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.
I propose "#:load file.cs"
https://github.com/dotnet-script/dotnet-script#consuming-a-s...
By dialect I mean that in CSX, the C# language has subtle differences in behavior compared to CS files (e.g., top-level methods are compiled differently). In 'dotnet run app.cs', the C# is exactly the same, hence it can be converted to a project (and we have a command for that - 'dotnet project convert').
> It's just a preprocessor - not a change to the C# syntax.
Should #:load work in normal C# files as well then? If yes, we would have two ways to include files - the normal way (include them in the project) or via #:load. If not, how would 'dotnet project convert' work? (It could paste the text but that's not very DRY if it's imported at multiple places.)
That's in short why #:load doesn't play very nicely with existing C# (it's a different paradigm of including other files). So the current proposal is to just make files in the same folder visible (just like they would be for a .csproj), because that's consistent with current C#, 'dotnet project convert' works, etc. But this proposal is not final yet, there are other options including what you suggest - see https://github.com/dotnet/sdk/issues/49193.