Roslyn: Add NuGet support in scripting APIs

[ManishJayaswal]

[daveaglick]

It's not totally clear what this issue is tracking - is it to add a new preprocessor directive like #r and #load that will support downloading and installing NuGet packages for scripts? If so, any estimate of the timeline (I know you can't give specifics, but I'm wondering if we're talking weeks or months)?

Perhaps most importantly, any idea how this will work? What will the directive look like? I'm trying to decide if I should add this myself to a script-based project I maintain (Scripty), and if I do, I'd like it to look similar to what's going to get put into Roslyn so I can rip my own implementation out later.

[jmarolf]

@daveaglick no idea of the scheduling for this other than the milestone the bug is currently bucketed in, but yes, the intent would be that you could reference a nuget package in a manner similar to #r or #load and have it added to the execution context for your script.

[tmat]

@daveaglick You can actually do it yourself today using extension points in scripting API that already exist.

The host gets the opportunity to interpret the content of #r directive as it needs to and return a metadata reference (see http://source.roslyn.io/#Microsoft.CodeAnalysis/MetadataReference/MetadataReferenceResolver.cs,15)

The host can check if the reference starts with nuget:, for example, find the corresponding nuget in the nuget cache and return the .dll that matches the current FX to the compiler.

#r "nuget:Newtonsoft.Json/9.0.1"

There is an open question of how to handle dependencies though (some kind of project.lock.json file).

Perhaps

csi MyScript.csx

would check if MyScript.csx.lock.json file is already present and if not restore and then run the script.

We could also have /restore command line option

csi /restore MyScript.csx

to just restore packages and generate MyScript.csx.lock.json file, but not run the script.

In the REPL we would manage .lock.json files for submissions in-memory.

[adamralph]

Of course, it's good that we can extend the scripting API, but the problem then is that we end up creating our own schema, a runner to support it, and, ultimately, scripts that are dependent on specific runners. IMHO this is so fundamental that it MUST be built into the scripting libraries itself, so we avoid an ecosystem where several different methods of importing NuGet packages into scripts start to appear. (BTW - it's already happening - see Cake).

[adamralph]

Is this a duplicate of https://github.com/dotnet/roslyn/issues/5654 ?