Reason for different versions of DNX depending on the OS

Asked

Viewed 54 times

1

A while ago I asked here about what . NET Execution Environment (DNX) really is. After reading the answer and the DNX Wiki I started to understand DNX as an interface between the virtual machine in which the managed code runs and the Operating System.

That is, I came to understand things as follows: when we work with . NET we are working with managed code that runs inside a virtual machine (which used to be only CLR). 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 this interface is DNX, correct?

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

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

While running the same command on Windows we have

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

In the case we realized that although in both cases we are simply requiring the . NET Core RC1 Update 1, what we gain 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

  • Operating system used - DNX name clearly indicates operating system

  • Processor architecture - DNX name clearly indicates x86 or x64 as well

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 that I now have of DNX I began to understand this in the following way: for being an interface between the virtual machine (CLR) and the Operating System, the 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 in which will run this virtual machine, to be able to correctly mediate between the virtual machine and the Operating System.

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

1 answer

0

Leonardo, this question is long overdue but remains open and very interesting to the community.

Imagine . NET as a set of interfaces. It’s a simplistic but functional example. You would then be programming accessing methods, events and properties of these interfaces.

The concrete implementation depends on each context, that is, on each operating system.

In native languages you need to compile your application for each target: 32 or 64 bits (in addition to internal code changes, obviously). 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 this case, when you see the packages you are basically visualizing the sets of implementations of the "interfaces" you used while programming.

Of course, it’s a little more complex than that, because not everything is an interface. But the idea is basically this, that your code runs over an abstraction layer, which transforms a lot of native and different Apis (Linux one way, Windows another, etc) into a standard set for you to work consistently.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.