6 ms·

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

by jug 1y 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/program-structure/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

munchler 1y ago
One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.
- eyegor 1y ago
  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.
  - nickpeterson 1y ago
    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
    - pshirshov 1y ago
      Half-baked adhoc features which didn't bring the language closer to Scala. Still no HKTs and typeclasses, call-site expansion can only be simulated with partials and text-level code generation, etc, etc.
      - athrun 1y ago
        Not bringing the language closer to Scala is a feature, not a bug though.
  - phillipcarter 1y ago
    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.
recursive 1y ago
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?
- banashark 1y ago
  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-tools-how-to-create https://learn.microsoft.com/en-us/dotnet/core/tools/global-t... * https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools 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/ 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-tools-how-to-create#package-the-tool 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.
  - recursive 1y ago
    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.
    - banashark 1y ago
      Ah rereading your original comment that makes sense. I found the announcement page here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... And here are the docs for “dotnet run” https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-r... You’re right that it’s missing this new functionality. The blog post has some details to get started, but I’m guessing that a docs link or section is missing for that. Dotnet covers quite a bit so the docs are accordingly larger than other projects that have a smaller scope. I will say though that while hit or miss, on average I’ve enjoyed their docs more than the average project.
electroly 1y ago
"dotnet tool exec" is not that feature; you're thinking of https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ 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 https://csharpier.com/docs/Installation you can now simply do "dotnet tool exec csharpier". This is like "npx" in the JavaScript world.
- Salgat 1y ago
  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.
  - SeriousM 1y ago
    I guess LinqPad will lose some users to this feature.
    - teh_klev 1y ago
      This isn't LinqPad's selling point. All that dotnet run *.cs has done is remove the need to have a project file for each "script" you write. LinqPad maybe has this feature but it's selling point is as a scratch pad to experiment with working with data and general futzing around.
      - Salgat 1y ago
        The .NET team said they're working on VS Code integration. LinqPad still has some unique features (mostly database related), but at least for me, VS Code + dotnet run will be sufficient for my needs. Worst case, I can just throw a breakpoint on my database IQueryable result.
- jug 1y ago
  Ah yes, that's the one I was thinking of. Got confused by this article.
tracker1 1y ago
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.
- Salgat 1y ago
  https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#referencing-nuget-packages-with-#:package 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.
  - tracker1 1y ago
    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.
    - electroly 1y ago
      The second link in the post you replied to explains how to use NuGet packages without using a .csproj file. You are not limited to in-the-box libraries. Not having a .csproj is the whole point of this feature; everything in this blog post is talking about things you can now do without a .csproj file. Repeating the link again here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#referencing-nuget-packages-with-#:package https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
ZenoArrow 1y ago
> 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/ https://blog.nuvotex.de/run-c-inside-powershell/
- moron4hire 1y ago
  That's not "embedding C#". That's runtime loading of .NET assemblies, which every .NET language--including PowerShell--can do.
  - ZenoArrow 1y ago
    It is embedding C#, if it was embedding assemblies it would be embedding compiled code. It's no different from inlining assembly in C.
xps 1y ago
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 https://github.com/dotnet-script/dotnet-script

by jug 1y ago

munchler 1y ago

One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.

eyegor 1y ago
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.
- nickpeterson 1y ago
  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
  - pshirshov 1y ago
    Half-baked adhoc features which didn't bring the language closer to Scala. Still no HKTs and typeclasses, call-site expansion can only be simulated with partials and text-level code generation, etc, etc.
    - athrun 1y ago
      Not bringing the language closer to Scala is a feature, not a bug though.
- phillipcarter 1y ago
  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.

recursive 1y ago

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?

banashark 1y ago
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-tools-how-to-create https://learn.microsoft.com/en-us/dotnet/core/tools/global-t... * https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools 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/ 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-tools-how-to-create#package-the-tool 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.
- recursive 1y ago
  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.
  - banashark 1y ago
    Ah rereading your original comment that makes sense. I found the announcement page here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... And here are the docs for “dotnet run” https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-r... You’re right that it’s missing this new functionality. The blog post has some details to get started, but I’m guessing that a docs link or section is missing for that. Dotnet covers quite a bit so the docs are accordingly larger than other projects that have a smaller scope. I will say though that while hit or miss, on average I’ve enjoyed their docs more than the average project.

electroly 1y ago

"dotnet tool exec" is not that feature; you're thinking of https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ 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 https://csharpier.com/docs/Installation you can now simply do "dotnet tool exec csharpier". This is like "npx" in the JavaScript world.

Salgat 1y ago
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.
- SeriousM 1y ago
  I guess LinqPad will lose some users to this feature.
  - teh_klev 1y ago
    This isn't LinqPad's selling point. All that dotnet run *.cs has done is remove the need to have a project file for each "script" you write. LinqPad maybe has this feature but it's selling point is as a scratch pad to experiment with working with data and general futzing around.
    - Salgat 1y ago
      The .NET team said they're working on VS Code integration. LinqPad still has some unique features (mostly database related), but at least for me, VS Code + dotnet run will be sufficient for my needs. Worst case, I can just throw a breakpoint on my database IQueryable result.
jug 1y ago
Ah yes, that's the one I was thinking of. Got confused by this article.

tracker1 1y ago

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.

Salgat 1y ago
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#referencing-nuget-packages-with-#:package 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.
- tracker1 1y ago
  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.
  - electroly 1y ago
    The second link in the post you replied to explains how to use NuGet packages without using a .csproj file. You are not limited to in-the-box libraries. Not having a .csproj is the whole point of this feature; everything in this blog post is talking about things you can now do without a .csproj file. Repeating the link again here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#referencing-nuget-packages-with-#:package https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...

ZenoArrow 1y ago

> 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/ https://blog.nuvotex.de/run-c-inside-powershell/

moron4hire 1y ago
That's not "embedding C#". That's runtime loading of .NET assemblies, which every .NET language--including PowerShell--can do.
- ZenoArrow 1y ago
  It is embedding C#, if it was embedding assemblies it would be embedding compiled code. It's no different from inlining assembly in C.

xps 1y ago

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 https://github.com/dotnet-script/dotnet-script