The road towards NetCoreApp2.0

[dotnet-script]

The road towards NetCoreApp2.0

[filipw]

that's awesome! ❤️

[filipw]

This would also be the time to drop project.json completely.
It doesn't work on OS X 10.13 anymore anyway and it will need to be ripped out of Omnisharp too.

I am now thinking the only supported nuget references should be via #r directives.

[seesharper]

I have all the stuff ready for omnisharp too. The project system will be dramatically simpler once we get the netcore20 branch ready. Doing the final cleanup now and will hopefully have a PR ready over the weekend.

[seesharper]

Here is my personal notes that I have kept during working with the netcore20 branch.

Dotnet.Script.DependencyModel

Provides an API to resolve runtime and compilation dependencies for csproj-based scripts.

This library has no dependencies to other dotnet.script libraries or other third-party packages, which means that it can be used by all script runners that needs to resolve runtime dependencies.

In addtion to being compiled for netstandard2.0, it is also compiled for net46 so that it can be used from OmniSharp.Scripting

Prerequisites

The Dotnet 2.0 sdk will have to be installed since we use dotnet restore under the hood to provide a DependencyContext from which we resolve runtime and compilation dependencies. On the execution side , this is not a problem since the user would have to have the dotnet cli installed anyway to execute dotnet.script. On the OmniSharp side, relying on the dotnet cli might sound a little more questionable. But since dotnet.script is the only script runner that actually understands either an explicit csproj file or a csproj file generated from script NuGet references, we should be good also on the OmniSharp side.
We could maybe have used the NuGet.Commands package which is the package that the dotnet cli uses under the cover, but the documentation here is virtually non-existent in addition to that it brings in a lot of dependencies that we don't necessarily want to have in OmniSharp.

Resolving runtime dependencies (Execution)

Action<bool, string> logger = (verbose, message) => { /* Log  */ }
var resolver  = new RuntimeDependencyResolver(logger);
var runtimeDependencies = resolver.GetDependencies(targetDirectory);

Note: If we pass true, we are being verbose and it should probably be logged as a debug statement. Otherwise it should appear in the standard log output.

Resolving packages with native/unmanaged dependencies

Some NuGet packages ship with native/unmanaged libraries. An example would be the Microsoft.Data.SQLite package that relies on the e_sqlite3 native library. This library needs to be accessible and discovered by the scripting runtime and we do that on Windows using LoadLibrary.

It is sort of a hack, but it seems to make the scripting runtime aware of the DLL. Preferably we would somehow set the NATIVE_DLL_SEARCH_DIRECTORIES property of the AppDomain, but we can't do that once the CoreHost is up and running. We simply come in to late.

The LoadLibrary method can only be used on Windows and the *nix counterpart, dlopen does not do the trick her.

Resolving compilation dependencies (OmniSharp)

Compilation dependencies (or compile-time dependencies) are meant to be used by OmniSharp.Script to provide intellisense for script files.

Action<bool, string> logger = (verbose, message) => { /* Log  */ }
bool enableScriptNuGetReferences = true;
var resolver = new CompilationDependencyResolver(logger)
var compilationDependencies = resolver.GetDepedencies(targetDirectory, enableScriptNugetReferences);

The reason that we deal with runtime dependencies on the execution side, is that the Roslyn scripting engine currently only supports compiling against runtime assemblies.

Take a look here for more information.

Say goodbye to project.json

For a long time during the beta days of .Net Core, it looked like Microsoft was heading for a new project format for .Net projects. project.json was introduced as the new lightweight project format and a lot of time and effort was put in to convert projects from the old csproj format to this new shiny project.json format. After a while or more specificially towards the end of the beta period, Microsoft decided to ditch project.json and go back to csproj. Not the old and rather verbose csproj, but a new simpler csproj format.

project.json practically died over night.

OmniSharp.Script still uses project.json as a way to provide a "runtime context" from which the compilation dependencies can be retrieved. This project.json file can contain references to NuGet packages and hence OmniSharp can provide intellisense for them as well.

The problem with project.json today is that we barely have any tooling left that can understand the format. NuGet stopped supporting project.json after version 3.5 and the dotnet sdk never understood the format after going out of beta. So for instance, if you want to use project.json today , you will need an outdated preview version of the dotnet sdk that most developers do not install.

IMHO, it is about time that project.json dies, also in the context of scripting

[filipw]

done