In the previous post, I announced that dotnet-script is now built as global tool and can be installed using .NET Core 2.1 preview SDK. However, by that time it was still based on .NET Core 2.0 runtime (it was possible to build and install .NET Core 2.0 tools using .NET Core 2.1 preview SDK).

Now we have even more cool news to announce - because dotnet-script is now a true .NET Core 2.1 application, and can be used to run scripts on top of .NET Core 2.1 runtime. We release quite often so let me do a quick rundown of all the new features since my last blog post.

.NET Core 2.1 🔗

As it’s been widely publicized, there is a ton of reason to run on a .NET Core 2.1 runtime. With the new dotnet-script version, what actually happens is that if you install it as the .NET Core 2.1 global tool, using .Net Core SDK 2.1.300 preview2 or higher, it will automatically choose .NET Core 2.1 runtime. The reason for that is that there was a breaking change between preview1 and preview2 of the .NET Core 2.1 CLI and only .NET Core 2.1 apps can be installed as global tools.

That said, depending on the currently active .NET Core SDK, dotnet-script can also run either as netcoreapp2.1 or as netcoreapp2.0, because for the time being it is cross compiled for both runtimes. You can use global.json file to control that. So if you install in any other way than as global tool, for example using Chocolatey or our install scripts you could still run in the .NET Core 2.0 runtime.

We are expecting some news on the future of .NET Core 2.1 and the release timeline too, so I think it’s great to be able to say that dotnet-script is absolutely ready for prime time here.

C# 7.3 🔗

Since version 0.24.0, released today, dotnet-script supports C# 7.3. This, for example, includes enum constrains or tuple comparison support.

C# 7.3 shipped with Roslyn 2.8.0 and Visual Studio 2017 version 15.7 on May 3rd. You can read about C# 7.3 features here.

Executing remote scripts 🔗

You can now run scripts that are located online (instead of just local physical files). You just need to pass the URL of the script as the file argument.

dotnet script https://link/to/my.csx

All the typical features of dotnet-script - such as #r “nuget:…” are supported. The script is never written onto disk (we don’t download it to a temp directory), it is executed entirely in memory, similarly to the eval functionality of dotnet-script, which allows you to pass a block of code as an argument.

This feature is particularly useful when sharing examples with others or when configuring CI pipelines, where you’d not want to store the CSX files in the CI server itself but would rather have it i.e in source control.

At its core, this is roughly the same as doing i.e. curl -L https://link/to/my.sh | sudo bash to run a remote script. Of course you have to be sure what is it that you are executing.

dotnet script -info 🔗

We’ve received feedback that it would be helpful to show the environment information for the dotnet-script. It makes sense, because it could be installed in multiple locations (depending on the installation method you chose), in different versions and it could be targetting .NET Core 2.0 or .NET Core 2.1. It also tries to automatically discover the platform you are on, which may or may not be correct.

All of that stuff is now captured in dotnet script -info command.
Here is Windows output:

~$ dotnet script --info
Version             : 0.24.0
Install location    : C:\Users\filip\.dotnet\tools\.store\dotnet-script\0.24.0\dotnet-script\0.24.0\tools\netcoreapp2.1\any
Target framework    : netcoreapp2.1
Platform identifier : win
Runtime identifier  : win10-x64

The same on my mac OS:

~$ dotnet script --info
Version             : 0.24.0
Install location    : /Users/filip/.dotnet/tools/.store/dotnet-script/0.24.0/dotnet-script/0.24.0/tools/netcoreapp2.1/any
Target framework    : netcoreapp2.1
Platform identifier : osx
Runtime identifier  : osx-x64

.NET 4.6.1 support for Dotnet.Script.Core 🔗

While dotnet-script is using the .NET Core runtime to run your scripts, the core library of dotnet-script, Dotnet.Script.Core is netstandard2.0 and is available on Nuget.

It now supports .NET 4.6.1+ so if you choose to use Dotnet.Script.Core as a scripting engine in your Desktop .NET application, you can benefit from all the features of dotnet-script (such as #r “nuget:…”, #load “nuget:…” and so on).

In order to take advantage of this functionality, you just have to define the current TFM that suits you (as it will be used to resolve the Nuget references and in general the compilation and runtime dependencies).

// run this before any other code
ScriptEnvironment.Default.OverrideTargetFramework("net461");

By default, the Target Framework is resolved from the current version of .NET Core runtime, and without setting the override, it throws on Desktop .NET.

For the future we are considering the possibility of supporting running Desktop .NET scripts from the dotnet-script command line tool as well.

Following #loads 🔗

dotnet-script will now try to discover all the #load directives before actually invoking the scripts. Beforehand, the #loads were only resolved at runtime.

This fixes a bug where #r “nuget:…” from a #loaded file where not supported (we only supported #r “{physical_dll}.dll”). This should be very helpful as it will allow you to move nuget dependencies out of the main file.

Plenty of other bug fixes 🔗

The detailed release notes, with links to relevant issues and PRs for releases 0.22.0 - 0.24.0 (all 3 releases since my last blog post) are available here on Github.

And, as always, if you’d like to help with anything or have any feedback, head over to the Github repo or ping me or Bernhard directly.