0.16.0
REPL
This release contains a C# REPL (Read-Evaluate-Print-Loop). The REPL mode ("interactive mode") is started by executing dotnet-script without any arguments.
The interactive mode allows you to supply individual C# code blocks and have them executed as soon as you press Enter. The REPL is configured with the same default set of assembly references and using statements as regular CSX script execution.
Basic usage
Once dotnet-script starts you will see a prompt for input. You can start typing C# code there.
~$ dotnet script
> var x = 1;
> x+x
2
If you submit an unterminated expression into the REPL (no ; at the end), it will be evaluated and the result will be serialized using a formatter and printed in the output. This is a bit more interesting than just calling ToString() on the object, because it attempts to capture the actual structure of the object. For example:
~$ dotnet script
> var x = new List<string>();
> x.Add("foo");
> x
List<string>(1) { "foo" }
> x.Add("bar");
> x
List<string>(2) { "foo", "bar" }
>
Inline Nuget packages
REPL also supports inline Nuget packages - meaning the Nuget packages can be installed into the REPL from within the REPL. This is done via our #r and #load from Nuget support and uses identical syntax.
~$ dotnet script
> #r "nuget: Automapper, 6.1.1"
> using AutoMapper;
> typeof(MapperConfiguration)
[AutoMapper.MapperConfiguration]
> #load "nuget: simple-targets-csx, 6.0.0";
> using static SimpleTargets;
> typeof(TargetDictionary)
[Submission#0+SimpleTargets+TargetDictionary]
Multiline mode
Using Roslyn syntax parsing, we also support multiline REPL mode. This means that if you have an uncompleted code block and press Enter, we will automatically enter the multline mode. The mode is indicated by the * character. This is particularly useful for declaring classes and other more complex constructs.
~$ dotnet script
> class Foo {
* public string Bar {get; set;}
* }
> var foo = new Foo();
REPL commands
Aside from the regular C# script code, you can invoke the following commands (directives) from within the REPL:
| Command | Description |
|---|---|
#load |
Load a script into the REPL (same as #load usage in CSX) |
#r |
Load an assembly into the REPL (same as #r usage in CSX) |
#reset |
Reset the REPL back to initial state (without restarting it) |
#cls |
Clear the console screen without resetting the REPL state |
#exit |
Exits the REPL |
Seeding REPL with a script
You can execute a CSX script and, at the end of it, drop yourself into the context of the REPL. This way, the REPL becomes "seeded" with your code - all the classes, methods or variables are available in the REPL context. This is achieved by running a script with an -i flag.
For example, given the following CSX script:
var msg = "Hello World";
Console.WriteLine(msg);When you run this with the -i flag, Hello World is printed, REPL starts and msg variable is available in the REPL context.
~$ dotnet script foo.csx -i
Hello World
>
You can also seed the REPL from inside the REPL - at any point - by invoking a #load directive pointed at a specific file. For example:
~$ dotnet script
> #load "foo.csx"
Hello World
>
#load with Nuget support ("Script Packages")
On the heels of our #r from Nuget for referencing Nuget packages, we are now introducing #load with Nuget support. It allows you to reference a Nuget package containing not assemblies, bur other CSX files and consume them directly against your script.
Script Packages
Script packages are a way of organizing reusable scripts into NuGet packages that can be consumed by other scripts. This means that we now can leverage scripting infrastructure without the need for any kind of bootstrapping.
Creating a script package
A script package is just a regular NuGet package that contains script files inside the content or contentFiles folder.
The following example shows how the scripts are laid out inside the NuGet package according to the standard convention .
└── contentFiles
└── csx
└── netstandard2.0
└── main.csxThis example contains just the main.csx file in the root folder, but packages may have multiple script files either in the root folder or in subfolders below the root folder.
When loading a script package we will look for an entry point script to be loaded. This entry point script is identified by one of the following.
- A script called
main.csxin the root folder - A single script file in the root folder
If the entry point script cannot be determined, we will simply load all the scripts files in the package.
The advantage with using an entry point script is that we can control loading other scripts from the package.
Consuming a script package
To consume a script package all we need to do specify the NuGet package in the #load directive.
The following example loads the simple-targets package that contains script files to be included in our script.
#! "netcoreapp2.0"
#load "nuget:simple-targets-csx, 6.0.0"
using static SimpleTargets;
var targets = new TargetDictionary();
targets.Add("default", () => Console.WriteLine("Hello, world!"));
Run(Args, targets);Note: Debugging also works for script packages so that we can easily step into the scripts that are brought in from Nuget
NuGet.config support
Inline package references now respect a local NuGet.config file. You can now create a NuGet.config file in the same folder as your CSX script and the inline packages will be installed using the sources from the NuGet.config.
Other features, changes and improvements
- the exceptions from compiling and running the scripts are now shown in red in the console PR: #184
- when running in debug mode and using the inline package references, we now print out the entire generated
csprojfile that was used to restore the packages from Nuget PR: #180 - the
-c|--configurationparameter was removed from the CLI - it wasn't used PR: #173 - installation script now ensures we install
dotnet-scriptmachine-wide PR: #176 - the included
Dockerfilebumped to .NET Core 2.0 PR: #172