Sdk: Scripting story, how to reference assemblies in script files

[smoothdeveloper]

I use .fsx and .csx files to do scripting, nowadays I'm relying on paket to list and download my dependencies (transitive dependencies included), which has a side effect of those assemblies to land under packages/packagename/../ folder which I can then easily reference:

#r @"../../packages/packagename/lib/netcore/packagename.dll"

// I can now easily use the package

What is the story with dotnet cli for this?

[smoothdeveloper]

@davidfowl, @enricosada it would be nice to figure out if I can rely on dotnet cli for scripting or if it is only to be used for projects.

I think scripting is a major way to get people to adopt the languages / platform when starting out, should they instead rely on paket project?

On a similar note, what is the story for dotnet cli and handling dependencies at solution level (this has to be consistent and managed in a lean way, again to favorise adoption).

[TheRealPiotrP]

@smoothdeveloper Scripting is not part of the core SDK but it would make for a great extension. I added this to the list in dotnet/cli#4672.

Can you share more details about how you'd like to handle dependencies at the solution level? I get this for tools, but are there other scenarios in your mind?

[forki]

Scripting has always been one of the most important features in F# land and the rise of things like ScriptCs shows that it's also important in C#. TBH I can't really understand how fsx/csx files are not supported from day 1. We asked for this on every occasion.

@smoothdeveloper regarding dependencies. It looks like NuGet will never get the concept of solution-wide dependencies. But fortunately the new MSBuild-based project format allows Paket to hook in again and we have https://twitter.com/sforkmann/status/790856841106493441 - so that's good.

I think paket's "load scripts" will be the way to go for including deps in fsx. But it's a long way.

[ghost]

In 2018, dotnet-cli without csx scripting ootb is one big setback.

According to https://github.com/dotnet/cli/issues/4672, this is up-for-grabs.

https://github.com/filipw/dotnet-script

Can we please combine the efforts put by @filipw and co and merge it upstream, so we get all roslyn compilers baked into .NET CLI?

[livarcocc]

This is something that is/should be worked out by the teams who own these scripting experiences, which is not the CLI. Closing this issue.