.NET Core doesn't depend on any installation?

Question

I've been reading about .NET Core and it seems really cool.

There is just one thing that is making me think and I haven't read it anywhere: when I set my asp.net 5 web app to target .NET Core and deploy it, this app doesn't depend AT ALL on the .NET framework installed on the machine that's going to host it?

I mean, the assemblies deployed already contain the CLR, the BCL and the project dependencies? So I can have mutiple web apps hosted in one single machine with different versions of .NET Core, right?

Answer 1

I mean, the assemblies deployed already contain the CLR, the BCL and the project dependencies?

They ship with whichever dependencies are in your project.json file. If you choose to deploy CoreCLR, the runtime will be shipped with your app in order for different apps to be able to run on whichever framework version they consume, side by side. The point is that all of the BCL is slowly packaged into separate NuGet packages which ship with your app, step by step removing the need to deploy the entire BCL.

Answer 2

If you choose to bundle (publish) the application with a runtime, then the application will use that particular runtime. If you deploy the application without it, then it will use the global runtime (if any) installed on that machine.

Yes, you can have multiple versions of CoreCLR side by side.

Answer 3

As my understanding goes deployed bundle can depend on .NET Execution Environment (DNX). But you can publish your bundle in a specific way with --runtime key, so DNX is included too.

Answer 4

Some of the other answers cover the BCL dependency aspect but it is important to distinguish that there is the runtime and the BCL (base class library). In the legacy (non dnx) world the lines were often blurred because both the runtime and the bcl were installed together at the system level.

Runtime (dnx) dependency

The dnx provides the launch point for the application. It includes the runtime, Just In Time compiler, bytecode compiler (Roslyn), unmanaged low level libraries, and a small amount of managed code. It is important to keep in mind that the dnx is identified by environment (windows, linux, mac, freebsd, etc), architecture (x86, x64, arm, etc), and runtime (currently coreclr or clr). It is also versioned and this versioning is separate from the bcl version. Newer versions of the dnx may be needed to resolve bugs, improve performance, and add features.

So the host machine will need the appropriate dnx (defined by architecture, environment, runtime, and potentially version in the event of breaking changes). There is more than one way to get the dnx on the host. One option would be to include it with the application (using dnu publish -runtime). Another option would be to use dnvm to install it 'globally'. Either way the runtime is a requirement.

As a side note the dnx for the full runtime (non-core) is only a facade. It is a method of making dnx applications work the same regardless of if they target the full framework or core framework. You may notice the dnx folder for full framework (i.e. dnx-clr-win-x64.1.0.0-beta4) is only about 10MB. If the full framework is not installed then the application will fail at runtime. In essence the dnx for full framework is only a stub which needs the full framework actually installed into GAC as part of system wide install to work.