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

[perlun]

I came here since after switching to a new machine, I no longer have a csi executable. :thinking: It used to work on my old machine. (This is on Linux btw.)

Trying to start a C# Interactive session inside JetBrains Rider also fails, without any error message.

[anpin]

Discovered the same on Linux last week and was bit disappointed. On Sat, Aug 20, 2022 at 11:50 PM, Per Lundberg @.***> wrote:
I came here since after switching to a new machine, I no longer have a csi executable. 🤔 It used to work on my old machine. (This is on Linux btw.) Trying to start a C# Interactive session inside JetBrains Rider also fails, without any error message.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[razzmatazz]

Btw, the alternative to csi on Linux (until it is released as dotnet tool) is csharp from mono-core

[perlun]

I came here since after switching to a new machine, I no longer have a csi executable. thinking It used to work on my old machine. (This is on Linux btw.)

Trying to start a C# Interactive session inside JetBrains Rider also fails, without any error message.

I finally found out where it was previously coming from. :tada:

$ dpkg -S /usr/bin/csi
mono-roslyn: /usr/bin/csi

Installing apt-get install mono-runtime mono-devel msbuild (from https://www.mono-project.com/download/stable/) gives me a working C# interactive console:

$ csi
Microsoft (R) Visual C# Interactive Compiler version 3.9.0-6.21124.20 ()
Copyright (C) Microsoft Corporation. All rights reserved.

Type "#help" for more information.
> 

[Regenhardt]

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

UPD: There is a ticket about it: #57939

Turns out I was thinking in the wrong context here - I was using csi only as shorthand for "C# Interactive", which is unfortunately because apparently csi.exe is basically the same thing except MS seems to have stopped updating it after .NET Framework 4.7.2 or so. #reset core only works in the C# Interactive window in Visual Studio unfortunately.

Which raises another question for people familiar with the inner workings (like @galvesribeiro maybe):

How to start the C# Interactive window like VS does?
Apparently that one supports .NET Core and also has actual IntelliSense and autocomplete.
I looked at the directory of the executable I assume to be the one VS is running, InteractiveHost64, and the config files are in json as opposed to the ones csi.exe has, which as .config files with xml within.
Edit: The .rsp file also loads more libs into context, fitting the idea of coreFx to add all the things as smaller libs on top of a smaller standard library.
Just executing that executable unfortunately does nothing, I guess it's not that simple.

As this would be a workaround, I don't think it should be its own issue.

It's also been 5 years guys what's going on do so few people at MS use csi?

[PathogenDavid]

How to start the C# Interactive window like VS does? Apparently that one supports .NET Core and also has actual IntelliSense and autocomplete. [...] InteractiveHost64

I believe that's the RPC server that Visual Studio interacts with to power the interactive window. The interactive window isn't just a terminal window, it's more complex than that. (Its source lives here)

---

I thought it had been mentioned in this thread previously, but if anyone's main motivation is having easier access to the REPL side of things: I can highly recommend @waf's CSharpRepl.

[joshcangit]

I see a few benefits with dotnet csi.

1. System-wide scripting same as dotnet fsi.

   Other scripting languages like Bash and Python can do this. Even Go can do this. AFAIK, dotnet-script is supposedly current user only.

2. Roslyn scripting.

   I don't know if any syntax differences but I think this could make Roslyn the default for .csx scripting shebang.

Didn't see any csi.exe or csi.dll. If this dotnet csi can't be done, then I think there has to be a way to install dotnet-script system-wide. Maybe by a package manager?

[tbrl0]

I do miss this feature as well

[mpawelski]

Looks like "C# interactive" is really dead. You can't even use never features there like "required" fields because you get error CS0656: Missing compiler required member 'System.Runtime.CompilerServices.RequiredMemberAttribute..ctor' (1,7): error CS0656: Missing compiler required member 'System.Runtime.CompilerServices.CompilerFeatureRequiredAttribute..ctor' errors.

Such a shame it was really a nice way of experimenting with code.

[Regenhardt]

> Environment.Version
[6.0.26]

Looks like it's still on .NET 6, can't find an open issue to update that.

[ZhiZe-ZG]

I still want this feature:

dotnet csi

Is there anything I can do to help finishing this?

[Regenhardt]

I still want this feature:

dotnet csi

Is there anything I can do to help finishing this?

You can use csharprepl (dotnet tool install -g csharprepl), it even has intellisense and autocomplete. When installed, just call csharprepl in your terminal.

[ZhiZe-ZG]

I still want this feature:

dotnet csi

Is there anything I can do to help finishing this?

You can use csharprepl (dotnet tool install -g csharprepl), it even has intellisense and autocomplete. When installed, just call csharprepl in your terminal.

Thanks a lot. But I mean csi looks more consistent with fsi. And the built-in script interpreter that does not require installation is a little more convenient to deploy.

[WeihanLi]

years passed, any news?

[vrubleg]

dotnet csi should be a thing that is supported by default on all platforms. This is surprising that C# Script doesn't get any love from Microsoft and feels abandoned.