As you may have read on this blog before, together with Bernhard, we have been working on a .NET Core and .NET CLI C# script runner, called dotnet-script, for a while now. Today I have a big announcement to make - we have recently released .NET Core 2.0 and .NET Standard 2.0 support!
These changes are part of 0.14.0 release that came out 3 weeks ago. We didn’t want to promote it that much, because - as it’s normally the case with .NET Core related stuff - the accompanying tooling wasn’t ready. In other words, there was no robust language services or intellisense story for writing .NET Core 2.0 scripts.
However, we are now ready with OmniSharp tooling too, which means you can enjoy C# scripting on .NET Core 2.0 in VS Code as long as you install the latest beta release of C# for VS Code. In parallel, we also already released a 0.15.0 version of dotnet-script.
Here is how to get started and a summary of what is new in 0.14.0 and 0.15.0.
Installation π
The latest releases of dotnet-script improved the process of installing the runner. The following installation methods are supported.
Chocolatey
choco install dotnet.script
Powershell
(new-object Net.WebClient).DownloadString("https://raw.githubusercontent.com/filipw/dotnet-script/master/install/install.ps1") | iex
Linux and Mac
Bash
curl -s https://raw.githubusercontent.com/filipw/dotnet-script/master/install/install.sh | sudo bash
The only prerequisite is to have .NET Core 2.0 SDK installed on your machine. You can then use the runner via .NET CLI:
dotnet script myScript.csx
If you are not interested in such auto-bootstrapping, you can also download the release binaries from the Github release page.
.NET Core 2.0 Support π
Your scripts are executed as netcoreapp2.0 and all the dependencies are automatically resolved using such runtime. The recommended way of loading Nuget packages is to use inline NuGet references which have been part of the runner for a while now. This allows your scripts to be entirely self contained.
For example, the following script consumes Newtonsoft.Json, version 10.0.3:
#! "netcoreapp2.0"
#r "nuget: Newtonsoft.Json, 10.0.3"
#load "user.csx"
using Newtonsoft.Json;
using System.Linq;
Console.WriteLine("Processing users!");
var rawJson = File.ReadAllText("users.json");
var users = JsonConvert.DeserializeObject<User[]>(rawJson);
foreach(var user in users) {
Console.WriteLine($"Found: {user.Name} - {user.Email}.");
}
Internally, dotnet-script uses .NET SDK and .NET CLI to restore the packages so the resolution process is identical to that you would experience when using csproj file and PackageReferences.
In fact, using package references from a standalone csproj file, rather than specifying them inline is also supported - as long as the csproj exists in the same folder as the csx file. That approach is conceptually similar to how scriptcs used the old packages.config set up.
Note that since 0.14 release project.json is no longer supported.
Tooling support π
In order to use the latest dotnet-script you will need to use OmniSharp built that supports it. Version 1.26.0 of OmniSharp contains support for .NET Core 2.0 based scripting.
That version of OmniSharp will ship with 1.13.0 release of C# for Visual Studio Code. You can install it already manually as beta version.
If you looked closely at the previous code snippet, you might have noticed a #! “netcoreapp2.0” directive at the top. It has no runtime meaning for dotnet-script, as the runner itself is .NET Core 2.0. However, OmniSharp supports CSX scripting against various runtimes - so that directive is needed to tell OmniSharp how to resolve compile-time dependencies; if it wasn’t there, OmniSharp would default to net46 as that is the default behavior of CSI.
Interestingly, dotnet-script shares it’s dependency resolution libraries - Dotnet.Script.DependencyModel and Dotnet.Script.DependencyModel.NuGet with OmniSharp to ensure that the dependencies are resolved the same way at compile-time (tooling) and runtime.
Performance improvements π
The start up time of your scripts should be 30-50% faster due to additional warm up being performed. In practice it means running (or rather, analyzing, compiling and running) a simple script improved from about 2.5-3s to about 1.5s.
Other π
The last two releases also contained a ton of bug fixes. Those are documented in the release notes, but the main issues resolved are related to binding redirects, symlink folder support, UNC folder support or support for folders with spaces.
Finally, the latest version of dotnet-script is running on top of Roslyn 2.4.0, which is the latest version of the compiler platform.
Get involved π
As always, we would love to hear your feedback or have you involved. The project is fully open-source and any contributions are always appreciated!
