.NET Core Platform Infrastructure

I’ve been using .NET Core for a few years now: I think the first version I installed was ASP.NET 5 beta 6, in mid 2015. I’ve installed a lot of different verions since then - my SDK folder currently contains 14 different versions - but it occurred to me recently that I’ve never really looked at what is being installed. So, I thought I’d take a quick look.

Installation Packages

The installation packages come in two different flavours: Runtime and SDK. Here’s what each of them contains:

• The Runtime packages supplies the dependencies you need to run an application built with .NET Core, including a dotnet command to execute the application.
• The SDK package includes everything from the Runtime package, and additionally the dependencies you need to build a .NET Core application. It also provides a dotnet command, but in this case it is the full .NET command line tool which allows us to build, restore, package, etc.

As is often the case, a diagram can describe more concisely the relationship between the SDK and Runtime packages:

Note that the SDK and Runtime have different version numbers. At the time of writing, the latest SDK is 2.1.4; the latest Runtime is 2.0.5, even when installed via the SDK package¹.

Installation on the Filesystem

Regardless of whether you are installing the SDK or the Runtime package, everything is installed to the same location on your filesystem. However, the exact location of this is dependent upon the platform you are installing to:

• on Windows, the installation directory is c:\Program Files\dotnet
• on MacOS it is /usr/share/local/dotnet
• on Linux it is /usr/share/dotnet²

Regardless of the platform you’re installing on, once we’re in the dotnet folder everything is nicely consistent across all platforms. Here it is on my MacBook; we see exactly the same folders on Ubuntu and Windows too.

There’s a lot of stuff here, and it’s not immediately apparent what all of it does. Let’s break it down based on what is providing it.

From the Runtime installation…

• dotnet - executes the .NET Core application. This is not the full .NET Command Line Tools
• host - contains hostfxr.dll, involved in bootstrapping the execution of a .NET Core application³
• shared - contains each installed version of the runtime libraries, organised by version number

Additionally from the SDK installtion…

• additionalDeps - contains dependency manifest (deps.json) files. These define dependencies for assemblies dynamically injected at runtime⁴
• dotnet - the .NET Command Line Tools
• sdk - contains each installed version of the SDK libraries, organised by version number
• store - the runtime package store. This allows us to pre-install package dependencies on a machine, reducing the size of our packaged application. Packages can be installed in here using the dotnet store command.

Again, let’s summarise this in a diagram:

So, there we go. No great revelations, but a mildly interesting diversion that helps fill a small gap of knowledge. It was interesting to read about the additionalDeps folder. Every application we build has a deps.json, generated automatically for us by the build system. I need to do a bit more reading to really understand how the dependency manifest mechanism works, and when I need to actually care about it.

Footnotes