Consider "self-contained" scripts

[dotnet-script]

Consider "self-contained" scripts

[adamralph]

The Roslyn team have already shown interest in building this into the Roslyn scripting libraries. Whatever happens here should be in line with what happens there to avoid fragmentation. I.e. scripts that run with runner A but not runner B. For that reason I would raise this again with Roslyn before doing anything here. E.g. dotnet/roslyn#6900

[filipw]

I am not entirely sure that project.json is the best way to specify dependencies since Microsoft is moving away from it.

something it's going to stay there for Nuget (whether it's nuget.json or whatever it's called, we'll see 😄

Regarding the other stuff, I tend to agree with Adam, yes.

That said, I still see some room for runner customization out there, especially as we work toward solving very specific problems. For example writing ASP.NET apps contains a lot of extra ceremony so I could imagine dotnet script aspnet foo.csx which would wire in a custom host that exposes ConfigureServices and such methods (see here). It has to be an opt in though (part of the Roslyn's scripting big selling points is Bring Your Own Globals, after all).

[adamralph]

The bring your own globals is indeed very powerful and I believe it's best used when hosting scripts in apps, where the scripts are specifically written for use in those apps. E.g. similarly to how VBA used to be used for app automation back in the day (and as the back bone of many large companies today 😰), where each app injects its context specific objects in, such as an Excel workbook, or Word document.

One temptation is to put boiler plate into globals but once we get better nuget support for scripting, it will be much easier to pull in those things via a nuget package. Of course, that won't work when the runner itself has to inject some context. For that case, perhaps there is an argument for some infra-level specific globals, e.g. an "ASP.NET flavour script" such as the one you linked to. For a generic runner, I'd like to see as much portability as possible.

[seesharper]

I was just wondering how you guys plan to move this forward. project.json is practically a goner starting with the preview 3 SDK. Roslyn Scripting is approaching 2.0, but I don't know if they have put in support for NuGet packages in load directives yet?

[adamralph]

IMHO the first thing to do is to check on the status of this within Roslyn scripting.

[filipw]

Roslyn Scripting is approaching 2.0, but I don't know if they have put in support for NuGet packages in load directives yet?

no

I was just wondering how you guys plan to move this forward. project.json is practically a goner starting with the preview 3 SDK

the scripting here will change up to use csproj instead

[filipw]

Fixed by #84