Add NuGet support in scripting APIs

[ManishJayaswal]

No description provided.

[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 #5654 ?

[waf]

For those following along, I think the custom MetadataReferenceResolver extension point won't work 100% right now, because nuget packages often include multiple DLLs (or have dependencies on other packages). Currently, the infrastructure around MetadataReferenceResolver doesn't support that:

roslyn/src/Compilers/Core/Portable/ReferenceManager/CommonReferenceManager.Resolution.cs

Lines 882 to 886 in 315c2e1

	if (references.Length > 1)
	{
	// TODO: implement
	throw new NotSupportedException();
	}

So it works fine with packages like Newtonsoft.Json that only include a single DLL, but does not work more generally.

As a workaround, we can still re-use the #r "nuget:PackageName" syntax, but it means our custom reference resolver won't actually install the packages; it needs to ignore this scenario, and custom code is needed to manually add MetadataReferences to our scripting session.

I'm happy to contribute a PR that would implement this TODO, although I'm not sure if that's a direction that the roslyn team would like to go.