Investigate how to use ScriptCS as the underlying execution engine

[lukebuehler]

ScriptCS is way ahead of CShell with many scripting possibilities and it supports many of the same things CShell tries to achieve. CShell could use the ScriptCS as the execution layer and then CShell development could focus on providing a rich UI.

Benefits would be:
-Leverage the fast paced development of ScriptCS
-Use their polished assembly management, from NuGet to local bin
-Switch between Roslyn & Mono compiler.

[pjkrill]

I may note this in any article I write

Paul Krill

From: Lukas Buhler <notifications@github.commailto:notifications@github.com>
Reply-To: lukebuehler/CShell <reply@reply.github.commailto:reply@reply.github.com>
Date: Monday, May 12, 2014 11:28 AM
To: lukebuehler/CShell <CShell@noreply.github.commailto:CShell@noreply.github.com>
Subject: [CShell] Investigate how to use ScriptCS as the underlying execution engine (#15)

ScriptCS is way ahead of CShell with many scripting possibilities and it supports many of the same things CShell tries to achieve. CShell could use the ScriptCS as the execution layer and then CShell development could focus on providing a rich UI.

Benefits would be:
-Leverage the fast paced development of ScriptCS
-Use their polished assembly management, from NuGet to local bin
-Switch between Roslyn & Mono compiler.

Reply to this email directly or view it on GitHubhttps://github.com//issues/15.

[lukebuehler]

yes please do, ScriptCS is awesome, it does not have an editor or an integrated environment. ScriptCS is more a powerful command line utility, but CShell could build upon that.

[khellang]

Sounds like it's becoming https://github.com/khellang/scriptcs-editor 😉

[lukebuehler]

@khellang, just took a look at ScriptCsPad, looks great.
I'm excited to get some attention from ScriptCs devs!

I think what I'm planing is a bit different. The main mode of execution would still be within the CShell REPL and not in a console running ScriptCs. The REPL implements ScriptCs.ScriptExecutor and makes the shell and its sinks (which are UI extension points for things such as: plotting, dumping to grids, dumping to html, and so on) available via a custom ScriptHost. Then, if the user wishes, he can right click a script and select "run with ScriptCS", which would open a console running the script using the ScriptCs.exe, there, of course, the CShell ScriptHost would not be available.

I'm planing to get rid of the .cshell file and make any selected folder the root of the workspace. Within that folder it would follow ScriptCs conventions, e.g., bin contains binaries, packages.config are the NuGet refs. I'm having an UI in the works to add NuGet refs.

Additionally there will be following convention: references.csx will contain external and GAC references, which can be managed by editing the file or using a UI dialog. Configuring CShell at the opening of the workspace can be done by creating a start.csx file, which has also access to the shell via the ScriptHost.

I'm almost having something working on my machine and will soon commit to the CShell/scriptcs branch.

Any feedback is welcome.

[lukebuehler]

Obviously this solves #14