@filipw filipw released this May 31, 2018 · 62 commits to master since this release

Assets 3

Change Log

0.25.0 (5/31/2018)

SUPPORT FOR .NET CORE 2.1 RTM SDK (2.1.300)

Full Changelog

Merged Pull Requests

  • Avoid loading version info unless option is specified (5/8/2018) #287 (atifaziz)
  • Fix NuGet exe resource name in NuGetRestorer (5/15/2018) #288 (atifaziz)
  • Include .NET Core version in the --info (5/9/2018) #289 (filipw)
  • Bumped github-changelog to 0.1.5 (5/10/2018) #290 (seesharper)
  • Add .csx extension to a new file if not specified (5/16/2018) #295 (SlowLogicBoy)
  • Bugfix/issue294 (5/16/2018) #296 (seesharper)
  • Remove unused ReflectionExtensions (5/24/2018) #299 (atifaziz)
  • Use standard text file reading/writing methods (5/24/2018) #300 (atifaziz)
  • use 2.1.300 on Travis (5/31/2018) #304 (filipw)
  • Use RTM build on Appveyor (5/31/2018) #305 (seesharper)

Closed Issues

  • Native image cannot be loaded multiple times (5/19/2018) #61 (mal4k)
  • Consider using AppContext.GetData("TRUSTED_PLATFORM_ASSEMBLIES") (5/19/2018) #161 (filipw)
  • Question: Is there a way to force to get latest version of nuget? (5/20/2018) #259 (stefandevo)
  • Version flag should print “just” the version number (5/7/2018) #276 (atifaziz)
  • Loading a specific script from a script package? (5/19/2018) #285 (pauldotknopf)
  • Terminating the script runner (interactive) (5/7/2018) #286 (tomgron)
  • Helloworld doesn't run as netcoreapp2.1 (5/10/2018) #291 (Sankra)
  • Debugging Helloworld from VS Code does not work (5/10/2018) #292 (Sankra)
  • KeyNotFoundException in NuGetSourceReferenceResolver (5/16/2018) #294 (filipw)

@filipw filipw released this May 7, 2018 · 95 commits to master since this release

Assets 3

Change Log

0.24.0 (5/5/2018)

Full Changelog

Merged Pull Requests

Closed Issues

@filipw filipw released this May 4, 2018 · 101 commits to master since this release

Assets 3

Change Log

0.23.0 (5/4/2018)

Full Changelog

Merged Pull Requests

Closed Issues

  • Pass the script path to scripts (4/25/2018) #121 (seesharper)
  • Failed to intall dotnet-script as global tool (4/25/2018) #265 (mdonatas)
  • Failure using System.Configuration.ConfigurationManager (4/28/2018) #268 (filipw)

@filipw filipw released this Apr 23, 2018 · 150 commits to master since this release

Assets 3

Change Log

0.22.0 (4/21/2018)

Full Changelog

Merged Pull Requests

Closed Issues

  • Dotnet Global Tool Install - FileNotFoundException (4/21/2018) #258 (stephenpope)

@filipw filipw released this Apr 17, 2018 · 173 commits to master since this release

Assets 3

Change Log

0.21.0 (4/17/2018)

Full Changelog

Features

  • Run scripts from HTTP locations (4/16/2018) #250. You can now run scripts from the web - just pass URL instead of filename i.e. dotnet script https://my.example.com/foo.csx
  • Scaffolding of default target framework into omnisharp.json (4/12/2018) #248. Next release of OmniSharp will allow providing framework version via a configuration, so it will be possible to write scripts without #! "netcoreapp2.0" directive and still get correct intellisense.

Bug fixes

  • Improved handling of runtime assemblies for Linux. This greatly improves the runtime experience and makes dotnet-script compatible with most .NET SDK compatible Linux distributions. (4/16/2018) #250

Other

  • Various documentation improvements
  • Build improvements - the solution itself now builds correctly on most linux distros (4/15/2018) #253

Closed Issues

  • Homebrew (Mac) (4/10/2018) #118 (seesharper)
  • Document GetScriptPath (4/17/2018) #137 (seesharper)
  • Let build.sh pick latest dotnet-script version programmatically (4/16/2018) #213 (andmos)
  • DLL/Type Loading error (4/16/2018) #226 (SlowLogicBoy)
  • Investigate scripts as global tools in .Net Core 2.1 (4/14/2018) #228 (seesharper)
  • Distribute dotnet-script as a global tool (4/10/2018) #240 (seesharper)
  • Why is hashbang/shebang #! abused? (4/16/2018) #246 (baran25)
  • [question] What about VB scripting? (4/14/2018) #247 (maximpashuk)
  • Doesn't build on Debian Stretch (4/15/2018) #252 (atifaziz)
  • Missing runtime assemblies on Debian Stretch (4/16/2018) #254 (filipw)

@filipw filipw released this Apr 10, 2018 · 205 commits to master since this release

Assets 3

Change Log

0.20.0 (4/10/2018)

Full Changelog

Merged Pull Requests

Closed Issues

@filipw filipw released this Mar 13, 2018 · 242 commits to master since this release

Assets 3

Features

  • scripts can now be run in Release mode - by passing a -c Release or --configuration Release flag #229

Bug fixes

  • removed the dependency on System.Runtime.Loader #224

Dependency Model packages

  • Dotnet.Script.DependencyModel has been updated to 0.5.0. It contains a bug fix where restore of inline nuget packages would not work on the bundled OmniSharp standalone MsBuild instance (so no Mono or Visual Studio installed on the machine) #233

@filipw filipw released this Jan 19, 2018 · 263 commits to master since this release

Assets 3

Features

  • dotnet script init now supports passing in the filename, for example dotnet script init start.csx. Additionally, the default created filename is no longer helloworld.csx, but main.csx #219
  • upgraded to Roslyn 2.6.1 #215

Bug fixes

  • handle #r and #load directives when using the dotnet script eval {code} feature #211
  • big performance improvement in the REPL #209
  • fixed possible MissingMethodException issues caused by JSON.NET version mismatch #214

Dependency Model packages

  • both Dotnet.Script.DependencyModel and Dotnet.Script.DependencyModel.Nuget got released to Nuget as part of release (versions 0.4.0 and 0.5.0 respectively). They contain updated references to Microsoft.CodeAnalysis.CSharp.Scripting and Microsoft.Extensions.DependencyModel #215

@filipw filipw released this Dec 11, 2017 · 298 commits to master since this release

Assets 3

Features

  • C# 7.2 support, Roslyn 2.6.0 upgrade #207

Bug fixes

  • Correctly handle binding redirects by always picking the highest version of an assembly #202
  • Load all the runtime assemblies from .NET Core App 2.0 #205

Other

  • *nix installation script now supports installing any version (instead of just latest) #201

@filipw filipw released this Nov 27, 2017 · 327 commits to master since this release

Assets 3

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

This 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.csx in 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 #loaddirective.

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 csproj file that was used to restore the packages from Nuget PR: #180
  • the -c|--configuration parameter was removed from the CLI - it wasn't used PR: #173
  • installation script now ensures we install dotnet-script machine-wide PR: #176
  • the included Dockerfile bumped to .NET Core 2.0 PR: #172

Bug fixes

  • implicit assembly references are now not as aggressive, resulting in less runtime assembly conflicts PR: #182. The recommendation is to use an inline #r "nuget: NetStandard.Library, 2.0.0" assembly reference
  • fixed assembly reference bug when loading native dependencies PR: #169