.NET Core 1.0.0 support #442
Conversation
First pass at getting the managed components to compile under RC2.
Got edge_coreclr.node to compile and run against the latest RC2 code. Currently requires you to specify a CORECLR_VERSION environment variable so that we know which framework to run against, but I'll start figuring out how to address that going forward. Also copied over a bunch of Microsoft's PAL methods from the CLI repository which has nearly eliminated the OS-specific code that I had.
You are no longer forced to specify a CORECLR_VERSION environment variable when running Edge.js: if none is supplied, we will find the maximum framework version that is installed and use that.
When an environment variable is used (either CORECLR_DIR or CORECLR_VERSION) to specify a particular CLR target, we will now throw an error if we fail to load the CLR from those targets. This is in contrast to previously where we would simply try to load it from the next available target.
Added support for parsing .deps.json in the unmanaged code.
Updated to (mostly) support dynamic compilation under RC2.
If the application dependency manifest has an entry for a bootstrap assembly (like Newtonsoft.Json) that is greater than the version listed in the Edge.js dependency manifest, use the application version in the bootstrap process.
If the dependency manifest for the application indicates a specific framework version via a dependency on Microsoft.NETCore.App, we will try to load that version of the framework instead of looking for the highest installed version.
Running applications can access runtime library and compile library data using DependencyContext.Default.
Native libraries in packages will now be correctly resolved and loaded by the dependency loader.
Minor modifications were made to deps_format.cpp to allow the setting of a runtime ID at runtime instead of relying on a compiler constant.
When checking the PATH for dotnet, we call pal::realpath on the result when we find it to get the actual CLR directory, which is required for non-Windows OSes.
When loading the application's dependency manifest file, we now merge in the shared runtime manifest, which gives us the fallback graph.
Initial code that moves towards properly abstracting the Edge.js managed runtime into a NuGet package that users are expected to reference in their project.json.
For scenarios when someone is just scripting .NET in Node.js without having a formal application (defined via EDGE_APP_ROOT), we have a bootstrap application that enables this by specifying the minimum necessary dependencies.
edge_coreclr.node now builds even if the .NET CLI toolchain is not installed, which is a requirement for running only published apps.
Updated a bunch of install and usage instructions to reflect the changes between RC1 and RC2.
Missed a few things...
|
What are the criteria that must be met before this PR (and over a dozen others, such as #437) will be merged? And what timeline? |
|
This PR takes priority over any other given the scope of the change. I hope to review and marge by early next week. |
When you depend on a module that requires edge and then you require edge yourself, edge_coreclr.node or edge_nativeclr.node will be loaded and initialized multiple times. For edge_coreclr, the CLR will try to load itself again which will, obviously, result in an error. So, we set the EDGE_NATIVE environment variable so that subsequent loads of the edge module will try to load the native code from the same location and therefore return the cached copy.
| 3. `"emitEntryPoint": true` should be present under `buildOptions`. You can add an empty `Main()` implementation to your project to accomodate it; this method will not be called, but is just a requirement in order for `dotnet publish` to generate a completely standalone app. | ||
|
|
||
| On your development machine, you would run `dotnet publish -r [target runtime for your production server]` (i.e. `dotnet publish -r ubuntu.14.04-x64`) to aggregate the package assemblies and native libraries necessary to run your application. You can copy the contents of the publish directory up to your SDK- and CLI-less server and use them directly in Edge.js by setting the `EDGE_APP_ROOT` environment variable to the directory on the server that you copied the published application to. | ||
|
|
There was a problem hiding this comment.
@lstratman what would be useful is "hello, world" samples for .NET Core demonstrating the various options (published app, on the fly compilation).
There was a problem hiding this comment.
Excellent idea, I will add a samples directory with the various scenarios, each with their own README.md file indicating how to compile and run them. Might not happen until early next week.
|
@lstratman Is there a reason Edge.js NuGet package does not have a dependency on Edge.js.CSharp, but instead the bootstrap project depends on both? |
|
Since Edge.js.CSharp is only needed for dynamic compilation of C# literals, I didn't want to force that dependency on applications that only reference pre-compiled assemblies. The bootstrap application, on the other hand, was in place so that applications can get up and running quickly with .NET languages quickly (without a project.json), which generally implied the use of dynamic compilation of literals instead of pre-compiled assemblies. |
|
Makes sense, thanks! |
|
@lstratman Have you ran the |
|
@lstratman never mind, found it. The entry point to start@node in node.dll has changed, probably as a result of my updating the compiler (since I did not change node version). |
|
@lstratman did you use |
|
@lstratman figured it out, never mind. |
|
This has been huge work @lstratman, thank you! All bits are now released /cc @ChristianWeyer Edge.js 5.9.2 on Nuget: https://www.nuget.org/packages/Edge.js/5.9.2 I will be out for a week now, I will do some promo around it when back. Maybe I will update to Node 6.x before. Again, fantastic job, this would not have happened without you @lstratman! |
|
👍👍👍👍 |
|
I notice the README still says "coming soon" for CoreCLR. Is that just out-dated?
|
Everything under #433.