Integrate csi to dotnet cli

[tmat]

Execute a script:

dotnet script.csx

Start C# REPL:

dotnet csi 

Similarly for F# and VB scripts.

[tmat]

See also https://github.com/fsharp/fslang-design/issues/167

[filipw]

might be worth a look https://github.com/filipw/dotnet-script

[tmat]

Thanks for the pointer @filipw. Do you think we could get rid of the extra verb "script"? It doesn't add much value since we know it's script from the extension.

[filipw]

The current extensibility around dotnet CLI forces you to have some verb, if you want dotnet.exe to pick up your extension - there is a good article here http://mattwarren.org/2016/10/03/Adding-a-verb-to-the-dotnet-CLI-tooling/.

That particular tool was created as a .NET Core app with a name dotnet-script, and as such, dotnet driver sees it as script. I think skipping it would require changes to dotnet CLI extensibility model.

There are additional guidelines here https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/developer-guide.md#adding-a-command, where they mention that "core" commands may be added to dotnet.dll directly. So in this case the functionality, being a core part of the C# compiler, could also be added straight in there, rather than use the general extensibility model.

[LYP951018]

What's the status of this?

[filipw]

FYI dotnet-script project has been upgraded recently to support .NET Core 2.0. It is also integrated into OmniSharp in order to provide language services in Visual Studio Code.

[adamralph]

I see that the current build produces C:\Code\dotnet\roslyn\Binaries\Debug\Exes\csi\netcoreapp2.0\csi.dll. If that was renamed to dotnet-csi.dll would we then not have dotnet csi? I'm not sure there's a reason to build it into the dotnet shell itself.

[adamralph]

BTW - is this not a duplicate of https://github.com/dotnet/roslyn/issues/6882 ?

[peabnuts123]

Would like to see this come to light

[Pvlerick]

dotnet csi xxx.csproj

would build the csproj then load it (and all its references) in csi. A man can dream...

[dasMulli]

Wouldn't this be a perfect fit for a global tool now?

dotnet tool install -g dotnet-csi / dotnet tool install -g csi

[filipw]

dotnet-script is already a global tool, and it supports everything CSI does + more (nuget etc).

in fact the syntax for nuget support was aligned with @tmat to ensure we don't invent anything non standard. it has OmniSharp support too.

what would you need a global CSI tool for? 😀

[dasMulli]

dotnet-script is fine just as well. I like to mess around with interactive mode from time to time. a few minutes ago I wanted to check some decimal numbers for bit masks. which I ended up doing using mono's csi. That's what made me think "I should check on the status of this on core"

I also like csi for small syntax demos, for which it would be great to have a tool that's available everywhere (e.g. vs command prompt) but a single dotnet tool install command is probably sufficient for this as well (since it would apply to both dotnet-script and dotnet-csi using this model).

[filipw]

dotnet-script has interactive mode too 🙂

personally I use csi for situations like you mentioned - where I want to be certain that it already exists on the target machine without any extra set up, and since it ships with msbuild tools, it's always there.

On a side note, csi also works on mono, just the default distro is missing System.Runtime.dll that has to be copied into the csi folder.

[galvesribeiro]

That would allow us to use C# Scripts on build systems that aren't MSBuild based (like gn for example) as the script language. For now, I have to install dotnet-script from @filipw until we have a REPL or some script runner like mono used to have.

[adamralph]

With dotnet run, there's little reason to use some kind of scripting workaround. You can just use a regular C# project: https://github.com/adamralph/minver/blob/master/build.cmd

[galvesribeiro]

@adamralph yeah but we don't want to mess with MSBuild are there are too much more than just build the project so we prefer the flexibility of a build script as code. We're just trying to avoid python since everything else we have is .Net anyway.

[adamralph]

@galvesribeiro I don't see what MSBuild has to do with it. All you need is:

• the .NET SDK (which you would also need if csi were integrated into the dotnet cli)
• a .csproj file, containing this at a minimum:

  <Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
      <OutputType>Exe</OutputType>
      <RollForward>major</RollForward>
      <TargetFramework>netcoreapp3.1</TargetFramework>
    </PropertyGroup>
  </Project>
  

• a Program.cs file

Compare this with a "script" (assuming csi were integrated into the dotnet cli):

• the .NET SDK
• a .csx file

So the only extra "noise" required for using dotnet run right now is a csproj file (and a few extra lines in Program.cs, but that also comes with the benefit that you can use the full power of csproj if you need it. And since it's a regular .NET project, all your favourite IDE's already work with it, and support full debugging etc.

[galvesribeiro]

@adamralph ok now I see what you meant.

That was my original approach. However, parameters being passed from gn on linux are based on --param (double -) which doesn't work with dotnet run for whatever reason (args is always empty).

Also, it worth to mention that once we have the .csx with the proper shebang(#!/usr/bin/env dotnet-script), I can call the script directly without need to invoke dotnet CLI like this: ./myscript.csx --param1 --param2.

[dasMulli]

The "csproj + Program.cs = Build Script" is basically what nuke (https://github.com/nuke-build/nuke) promotes and makes easy.

Note that in theory dotnet run should support passing all sorts of args after a -- separator (dotnet run -c Release -- --foo --bar) but do open isssues on dotnet/sdk if it doesn't work for you..

[adamralph]

It's also the model for https://github.com/adamralph/bullseye

[dariens]

dotnet-script is a very nice project... However, I am still in favor of having a 'dotnet csi' command included in the dotnet CLI to make sure that it is being released and is compatible with all versions, including previews, of dotnet... Currently, dotnet-script is only compatible up to dotnet 3.1.0. I am working on testing dotnet preview 5.0.0 and there is no way, that I know of, to run .csx files with this version. I have mainly been working with F# and must admit that it is nice for 'dotnet fsi' to be supported for every release since dotnet 3.0 (including previews).

In addition. I would assume that adding the 'dotnet csi' command would allow the OmniSharp project to more easily integrate a C# REPL into VS Code in the same manner that the Ionide-FSharp project includes an F# REPL. See https://github.com/OmniSharp/omnisharp-vscode/issues/1239 . With all the new functional features expected in C# 9, the REPL will be very much appreciated by the group of functional first programmers that are going to start taking C# seriously as a functional friendly language, and who are used to constantly utilizing the REPL during development.

[John0King]

so what's the plan for csi after years that fsi been release in dotnet sdk ?

[dzmitry-lahoda]

i have to use python for last 4 years. just because install python gives python in cmd, while installing dotnet does not gives me csi or fsi..

[Happypig375]

dotnet gives dotnet fsi. You can use it via dotnet fsi xxx.fsx.

[John0King]

anything new? I see the blog that vs will use dotnet fsi in f# interactive window , so csi will only work in VS instead of cli ? https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/#f-tooling-net-core-the-default-for-scripting

[Regenhardt]

Yeah where's dotnet csi? Was surprised to see dotnet fsi included but not dotnet csi.

[vrubleg]

I use existing csi for build scripts. Very useful. It allows to use the latest language features also, but seems like the latest library features from .NET are not available, it seems like it is still executed with .NET Framework 4. It would be nice if dotnet csi would allow to use the latest .NET 6+.

[Regenhardt]

@vrubleg you can switch csi to use .NET core using "#reset core"

[vrubleg]

@Regenhardt Is it documented anywhere? It doesn't work for me: error CS1024: Preprocessor directive expected.

UPD: There is a ticket about it: https://github.com/dotnet/roslyn/issues/57939