Back to articles

DNX, .Net Core, ASP.Net vNext, who is who?

I’m writing this blog after we have done several projects (some of them were commercial, some internal) with these technologies at Kvinivel and discovered a lot of things that are not covered by the documentation.

Let’s try to understand the place of every project on the global picture

Many of us already know about the new version of .Net. There are a lot of resources saying that it will be open source, will run on Linux and OS X without mono and a lot of other things. And some statements can disappoint because they conflict with each other.

Let’s review available projects

First, let’s understand what DNX and .Net Core are and how they relate to each other.

Hmm… two projects from MS with the same goals and the same features. And yes, that’s true DNX and .Net Core currently gives us almost the same functionality. And these two sites together with ASP.Net and VS Code web site bring a lot of misunderstanding about what the next .Net next version is. What is the reason for it? The answer is here ( “We’ve been using DNX for all .NET Core scenarios for nearly two years… ASP.NET 5 will transition to the new tools for RC2. This is already in progress. There will be a smooth transition from DNX to these new .NET Core components.” Looks like DNX will be replaced by tools from .Net Core.

Ok, what about .Net Framework 4.6 and Mono? .Net Framework ( will continue its evolution as a framework with WPF and other windows specific stuff, and it will be compatible with .Net Core. It means that it will not duplicate core functionality, but instead of it will offer additional services. And as it was before, the most interesting things like WPF will be only MS Windows compatible. The same story with mono, I think.

Let’s summarize

.Net Core — set of cross-platform tools to build applications, cross-platform execution tools, set of cross-platform core libraries (like System, System.Runtime, System.IO, etc.)

DNXobsolete (at least for ASP .Net 5) set of cross-platform tools and runtime environment with almost the same feature-set as in .Net Core

.Net Framework – set of libraries to develop windows desktop and web applications some the assemblies may be cross-platform as far as the assembly format is the same in all described technologies.

Mono — set of libraries that partially replaces .Net Framework under Linux and OS X, execution tools and build tools.

The assembly format is the same, so mono can execute Core or Framework assembly and vice versa. The most significant problem except P-Invokes to Win API is references. Currently, all described frameworks have different functionality distributions across assemblies. So sometimes you will not be able to start the application because the application will search for class C in assembly A, but in actual runtime class C will be located in assembly B.

Some additional notes about building tools

Both .Net Core and DNX have a new project file format project.json. It aimed to use file system structure as project structure and allows building applications for different platforms at the same time. As a result, you will have a set of assemblies that are referencing the correct assembly for every class.

Both tools work on Linux and OS X (OS X was not tested by me yet).
One of the significant problems is debugging under Linux now. To debug the application we need .pdb (.mdb) file that binds binary assembly with source code files. DNX tools are not able to produce any debug files, .Net Core tools can produce *.pdb files but VS Code and MonoDevelop need *.mdb under Linux to debug. So now it’s better to use mono under Linux if you would like to debug 🙂 Even if you are going to use VS Code.

One of important things is that .Net Core build tools can produce native small Linux executables to start applications without “mono app.exe”.

My next blog will be about build tools and how to set up a build environment under Linux.

It also could be interesting to You

About reinvention of a wheel, Agile and Linux way

How often in software development do you think about rewriting some 3rd party module from scratch? The popular vision of the problem says that we should not reinvent a wheel and use existing paid or…

“Why do people refuse to use WebRTC? Is it really its quality question?”

As a CEO who has 15+ years of software development, I take part very often in the first call with our clients. Very often, I can hear something like “We should like to move away…