What is DNX really?

7

Long time ago I asked here o which is the runtime environment , especially on the .Net platform. It turns out that now .Net has the DNX which is the ".Net Execution Enviroment". In practice we used DNX to run software developed with the new version of .Net, having support using the usual CLR or Core CLR.

At this point there is my doubt. From what I'm seeing there is a difference between the runtime environment (in the CLR or Core CLR case) and the execution environment (in this case the DNX). It seems to me that DNX is just for choosing a runtime environment and somehow connecting the software to the runtime environment , but I'm not quite sure if this is it and how this works.

In this case what is DNX really and what is the real need of it? Also, what is its relationship to the runtime environment ?

    
asked by anonymous 26.09.2015 / 02:10

1 answer

7
  

This is no longer valid with the implementation of CLI - Command Line Interface

By and large, all technology that has emerged from the opening of the .Net code and the more modular architecture is consolidating and getting to the point of having everything you need to use in production.

You should already know that CoreCLR replaces .NET with a platform full of things to make the applications work. But if you look closely the CLR is just one of the components of. Net. So CoreCLR does not completely replace .Net. Some components that take care of the operating infrastructure of applications developed using CLR are required to start the application.

Remember that the moment you install. Net on your computer, you practically create a second operating system running there. If it is in the directory where .Net is possibly installed inside C:\Windows you will see that there is something very complex there. That's not just the CLR. It has the compiler, environment managers responsible for exception handling, memory management, threads, processes, domains, code security, and so on. It is the native host that ran the managed applications.

Well, DNX is this but with a different, more modular and less intrusive philosophy in the operating system, such as .Net. It's a more conventional way to call the managed application, that is, you call the DNX that will call the rest. On .Net this is more transparent. A lot of people think that they are running a real executable when executing a .Net. Note that I am not saying that it is an exact substitute.

The official definition says that it is a SDK specific to .Net applications.

The main motivation of it is to host ASP.Net applications, since it allows the application to run without relying on an extra infrastructure, such as IIS, for example. But it is not restricted to this.

I do not even have to say that one of his differences for .NET is that it was made to run on a variety of platforms, and the original .Net remains unique to Windows. For its philosophy it should be even difficult to port .Net in the current form to other platforms. And Microsoft is not even interested in this. Doing the same system load environment and application would be very complicated on other platforms. This is why Mono and Java do not do this.

In the answer I've given ( linked in the question above) I give more details about the fact that there are several hosts , several versions of the CLR, some custom. How to manage all this, how to have something in common that makes all this work? The answer is DNX. Obviously there are other ways to run a .Net application without DNX. It is one of the ways to do this.

It also helps meet more modern demands. It handles in a modern way with configurations, packages and updates. It can manage the dependencies and you just pull to a deploy what it's really going to use.

Retrievedfrom DNX Wiki .

I know I've forgotten some things he does, I try to improve over time. If you have something specific you need to know, be translated from the documentation, leave a comment.

It's good to keep an eye on what's new. DNX is being modified .

    
26.09.2015 / 04:20