C# and .NET Core scripting with the "dotnet-script" global tool
You likely know that open source .NET Core is cross platform and it's super easy to do "Hello World" and start writing some code.
You just install .NET Core, then "dotnet new console" which will generate a project file and basic app, then "dotnet run" will compile and run your app? The 'new' command will create all the supporting code, obj, and bin folders, etc. When you do "dotnet run" it actually is a combination of "dotnet build" and "dotnet exec whatever.dll."
What could be easier?
What about .NET Core as scripting?
Check out dotnet script:
C:\Users\scott\Desktop\scriptie> dotnet tool install -g dotnet-script
You can invoke the tool using the following command: dotnet-script
C:\Users\scott\Desktop\scriptie>copy con helloworld.csx
Console.WriteLine("Hello world!");
^Z
1 file(s) copied.
C:\Users\scott\Desktop\scriptie>dotnet script helloworld.csx
Hello world!
NOTE: I was a little tricky there in step two. I did a "copy con filename" to copy from the console to the destination file, then used Ctrl-Z to finish the copy. Feel free to just use notepad or vim. That's not dotnet-script-specific, that's Hanselman-specific.
Pretty cool eh? If you were doing this in Linux or OSX you'll need to include a "shebang" as the first line of the script. This is a standard thing for scripting files like bash, python, etc.
#!/usr/bin/env dotnet-script
Console.WriteLine("Hello world");
This lets the operating system know what scripting engine handles this file.
If you you want to refer to a NuGet package within a script (*.csx) file, you'll use the Roslyn #r syntax:
#r "nuget: AutoMapper, 6.1.0"
Console.WriteLine("whatever);
Even better! Once you have "dotnet-script" installed as a global tool as above:
dotnet tool install -g dotnet-script
You can use it as a REPL! Finally, the C# REPL (Read Evaluate Print Loop) I've been asking for for only a decade! ;)
C:\Users\scott\Desktop\scriptie>dotnet script
> 2+2
4
> var x = "scott hanselman";
> x.ToUpper()
"SCOTT HANSELMAN"
This is super useful for a learning tool if you're teaching C# in a lab/workshop situation. Of course you could also learn using http://try.dot.net in the browser as well.
In the past you may have used ScriptCS for C# scripting. There's a number of cool C#/F# scripting options. This is certainly not a new thing:
- Mono scripting
- ScriptCS (Filip was core on this)
- Roslyn Scripting APIs (Roslyn is underneath most scripting environments)
- CS-Script
In this case, I was very impressed with the easy of dotnet-script as a global tool and it's simplicity. Go check out https://github.com/filipw/dotnet-script and try it out today!
Sponsor: Check out the latest JetBrains Rider with built-in spell checking, enhanced debugger, Docker support, full C# 7.3 support, publishing to IIS and more advanced Unity support.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Also, please use the word "super" less often, no matter what. When I hear "easy", I usually pay attention. When I hear "super easy", I dismiss it as advertisement.
And just to be clear, I am only refering to the dotnet stuff here ("dotnet new", "dotnet run" and whatnot). I am well aware of the benefits of scripting to automate administrative stuff, of course. PowerShell is my friend ;)
<sarcasm>You probably haven't heard of Bash, have you? It enables PowerShell scripting without all these fluff.</sarcasm>
@NinjaSquirrel
Your comment seems a little bit off-topic.. Dotnet script is a great way to lower the barrier of entry for C-Sharp as a "scripting language". Java 11 does the same thing, it allows you to run a single *.java file without compiling it (with a help of shebang).
Second, dotnet command line tools are also awesome. Dotnet is not being now only "windows/visual studio" specific . It now runs everywhere, which means that people will try to create apps with vim/emacs on linux, godknowswhateditor MacOS uses and so on.
Again look into the Java world (i wont even start with JavaScript here). People have to download Java SDK and Maven and use Maven to create projects from archetypes. It is almost the same thing, but dotnet delivers it as a part of SDK for the best user experience possible, and to make sure every one uses the same project structure and best practices from MS.
Although your point about multi-platform support seems to be valid, I'd still say that just having the option of working on the command line doesn't make it the new "cool" way of doing it. Otherwise there would be no GUIs at all. The .NET framework is not the first multi-platform "thing" in the IT world and others simply provide useful GUI implementations additional to the CLI option. For example, in 99% of all cases I use some kind of GUI to copy files (regardless of the OS I'm on) and still I have automated my backup logic using robocopy - but nobody advertizes robocopy to be the one and only "cool" way of copying a file.
Also, I doubt that any real-life .NET projects are being done in vim or emacs, but in an appropriate IDE, where GUI wizards exist for so many reasons.
Again, I don't hate the CLI or scripting. I just can't follow the reasoning behind the hype that it's the new stylish way of doing the same stuff that we've done for centuries without learning new CLI commands for every tool or framework.
.NET Core == edit config files and *yuck* maintain someone elses 4 year old config file in 2024.
"You probably haven't heard of PowerShell, have you? It enables .NET scripting without all these fluff."
Seems he/she doesn't know *nixes have several shells. So if I want may change my shell language, sir?
Tks
From within an empty folder
dotnet script init
This will create the launch configuration we need to debug a script.
Start code in oir current folder.
code .
That's all. We can now set a breakpoint anywhere in our script(s) and hit F5 to launch the debugger.
Notice that we also provide true intellisense like we are used to in a "normal" C# project.
Comments are closed.