Reason for different versions of DNX depending on OS

Question

Reason for different versions of DNX depending on OS

Navigation

#1 by (0 votes)

1

Some time ago I asked here about which really is the .NET Execution Environment (DNX). After reading the answer and the DNX Wiki I came to understand DNX as an interface between the virtual machine on which the managed code executes and the Operating System.

In other words, I started to understand things like this: when working with .NET we are working with managed code that runs inside a virtual machine (formerly CLR only). This virtual machine needs an interface with the operating system, a software responsible for initializing a process to host the virtual machine, initialize it, take care of dependencies, etc. In the new .NET that interface is DNX, correct?

It turns out that DNX has several versions. For example, if we use dnvm upgrade -r coreclr on Linux x64 we get a DNX named

dnx-coreclr-linux-x64-1.0.0-rc1-update1

While running the same command in Windows we have

dnx-coreclr-win-x64-1.0.0-rc1-update1

In case we realize that although in both cases we are simply requiring .NET Core RC1 Update 1, what we get as DNX depends:

From the chosen CLR version - this is reflected in the fact that DNX has in its name the version of CLR 1.0.0-rc1-update1
From the operating system used - the DNX name clearly indicates the operating system
From the processor architecture - the DNX name indicates that it is also x86 or x64 clearly

For a long time I wondered why: if there is simply a .NET Core and a .NET Full, why are there several versions of DNX?

With the understanding I now have of DNX, I came to understand this as follows: Because it is an interface between the virtual machine (CLR) and the Operating System, DNX depends on the chosen virtual machine (CLR or CoreCLR, as well as its version) and also depends on the specifications of the Operating System on which to run this virtual machine, to be able to mediate correctly between the virtual machine and the Operating System.

That's really the reason why, although we only refer to .NET Core as .NET Core (ie, one thing only), are there several versions of DNX? And, consequently, is this way of understanding DNX the right one? If not out there, what is the real reason for having all these different versions of DNX?

.net clr asp.net-core runtime dnx

asked by anonymous 07.12.2015 / 14:30

1 answer

BibTeX gives error in abbreviation [closed] Show PDF in browser without printing or recording

score 0 · Answer 1

Leonardo, this question already has a lot of time but remains open and very interesting for the community.

Imagine .NET as a set of interfaces. It is a simplistic but functional example. You would then be scheduling accessing methods, events, and properties of those interfaces.

Concrete implementation depends on each context, that is, on each operating system.

In native languages you need to compile your application for each destination: 32 or 64 bits (in addition to internal code changes, of course). You also need to prepare your application in different ways to run on Linux or Windows.

Other frameworks (like java) do the same, but in a more hidden way. In case, when you see the packages you are basically viewing the implementation sets of the "interfaces" you used while programming.

Of course it's a bit more complex than that, because not all interfaces are. But the idea is basically this, of your code running over an abstraction layer, which turns a lot of different native APIs (Linux one way, Windows another, etc) into a standard set for you to work consistently .