Comment by jug
4 days ago
My favorite .NET 10 feature so far is not within the .NET library itself, but `dotnet tool exec` to run C# files as scripts without a build step. This has been available in F# for a long time via `dotnet fsi`, and for C# also via the third party cs-script tool. It took a surprisingly long time to officially reach the primary .NET language!
I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell. You may balk at the idea for causing a ton of cruft for people who don’t need it; ”a whole new scripting language!” But the thing is — PowerShell already builds upon .NET so supporting a new language is a rather small effort (relatively speaking) if it happens to be a .NET language. And C# just feels so much better for me to code in when the scripts grow in size. I’m not sure I’ll ever become friends with the implicit returns. C# has become particularly suitable for scripting with the recent developments in the language: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
"dotnet tool exec" is not that feature; you're thinking of https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... which they added to "dotnet run". "dotnet run my-cool-thing.cs"
"dotnet tool exec" is so you can run third party command line tools like csharpier that previously required "dotnet tool install" before you could use them. For example, in https://csharpier.com/docs/Installation you can now simply do "dotnet tool exec csharpier". This is like "npx" in the JavaScript world.
dotnet run *.cs is my favorite new feature for scripting. It has basically replaced powershell for me. It's trivial to script powerful operations now.
I guess LinqPad will lose some users to this feature.
2 replies →
Ah yes, that's the one I was thinking of. Got confused by this article.
> I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell.
You can embed C# in PowerShell scripts, and you have been able to do so for a long time. This webpage has a couple of examples of how this can work:
https://blog.nuvotex.de/run-c-inside-powershell/
That's not "embedding C#". That's runtime loading of .NET assemblies, which every .NET language--including PowerShell--can do.
It is embedding C#, if it was embedding assemblies it would be embedding compiled code. It's no different from inlining assembly in C.
One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.
F# has been a third class citizen for a long time... Last I heard the entire f# team was ~10 people. Pretty sure "find references" still doesn't work across c# and f# (if you call a c# method from f# or vise versa). That also means symbol renames don't work correctly.
I agree, but somewhat paradoxically, F#’s lack of new features kind of becomes a feature. Have you seen the number of C# features added in the last 5-10 years? It’s crazy
2 replies →
The F# team is smaller than 10 people, always has been.
~10 people is the size of the C# and VB language design and compiler team. The IDE side of things for C# and VB is about another 20+ people depending on how you count, although they also build and own infrastructure that (a) the F# team sits atop, and (b) is used by other languages in Visual Studio and is used in VS Code.
The #1 thing that people always end up surprised by is just how small and effective these teams are.
Now I'm curious if C#/.Net 10 is smart enough to ignore the shebang line. Personally, I've tended to use Deno/TS for my more advanced shell scripting... the main runtime is a single executable that works fine in user context, and dependencies can be loaded/cached at first run.
Of course, with C# as a shell script, you'd likely be limited to just in the box libraries or have to setup a project for sake of running a script, like I've had to do with Node or Python stuff.
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
"dotnet run app.cs" natively supports shebang lines and nugets. The only requirement is to make sure the .net sdk is installed on your computer.
I'm guessing, however that using nuget packages means having at least a .csproj file near your .cs file with the packages defined. And downloading the packages, compiling to a space under the .csproj path, similar to a node_modules directory (bin and obj for .Net).
What I like about Deno, is the packages are downloaded/cached to a shared location not next to your script, and you don't need additional files configured. At least for shell scripts.
I'm glad shebang works, that will actually help with some process checking I'm wanting to do from CLI without launching my entire services around it.
1 reply →
I've wanted this for a long time. After reading this link, and the MS release announcement, I still don't understand what a "tool" is, or how you can use `tool exec` to run a single *.cs file. Is there a straight-forward recipe anywhere for doing this targeted at absolute simpletons?
Well if you're familiar with the node ecosystem it's a corollary for npx/bunx/etc.
It is so that folks can build and run "tools" that are executed, utilizing the nuget ecosystem.
Relevant links in the dotnet docs (was just a quick google away):
* https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...
* https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...
It's actually a top-level doc section in the primary dotnet docs (https://learn.microsoft.com/en-us/dotnet/).
To boil it down: you create a console app, add a couple of attributes to the solution file (https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...). Packaging and publishing to nuget (if you want to share with others) is via `dotnet pack` and `dotnet nuget push` with some flags.
I do have to say it's actually very well documented.
Sorry for being unclear. Using tools isn't my goal. I want to run a single *.cs file from the console. It may be possible to achieve this using tools, but I don't know how. I did read the resources I could find, and didn't find any information about this.
1 reply →
The docs are terrible right now (prerelease and all that), but to get started:
1. Install the dotnet sdk preview
2. Make a .CS file with top level statements.
3. dotnet run <file>
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
> I still don't understand what a "tool" is
"A .NET tool is a special NuGet package that contains a console application. You can install a tool..."
https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...
it's actually very similar to the node.js / NPM equivalent, which came first:
https://docs.npmjs.com/downloading-and-installing-packages-g...
Sorry for confusing you. I can't edit the post now. The command is dotnet run script.cs. The tool stuff is about something else unrelated; NuGet installable CLI executables.
It's great that Microsoft added this as an official feature but there has been an open-source third-party solution that does exactly the same thing for a long time: https://github.com/dotnet-script/dotnet-script