Hacker News Reader

"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.

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.

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.

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

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.

Not bringing the language closer to Scala is a feature, not a bug though.

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-...

"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.

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-...

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...

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.

Ah rereading your original comment that makes sense.

I found the announcement page here: 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-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.

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-...

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.

> 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...

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