In a previous post on the upcoming ASP.NET ‘vNext’ release, I covered all of the terminology around ‘Project K’ – which is what it was known as in early betas.   Things have moved along a lot since then, and with that has come a change in terminology as the release gets closer.  The trend of calling everything ‘K’ is no more – sadly in my opinion as I liked the quirkiness of it.

This post will cover the new terminology, relate it back to the Project K era terminology and relate that back to existing ASP.NET (1-4) concepts where possible.  Again, this is intended as a primer for the existing ASP.NET developer to learn what is coming next and get themselves familiar with the changes.

About ASP.NET vNext – forever to be known as ASP.NET 5

ASP.NET 5 is a major departure from versions 1 through 4.6 (the latest release).  There are many breaking changes and completely new ways of doing things.  These types of changes are always painful – the payoff is the ability to build smaller, more focused code which carries less bloat and only includes what you need.   In a world where cloud services are increasingly the choice of deployment models, it doesn’t pay to lug around large libraries of unused code. 

In addition, ASP.NET 5 departs from being a Windows/IIS only deployment.  Cross platform native deployment is now possible, which increases the audience for the software while allowing leverage of even more of those cloud service platforms. 

It’s all exciting changes – so let’s look at some of the specific technology terminology.

ASP.NET 5 Terminology Definitions

Core CLR

The Core CLR is the central Common Language Runtime used in ASP.NET 5 applications. The Core CLR does not come complete with all the various .NET libraries as prior installs of .NET did (whether you needed them or not, and in most cases with a web application – not).   The intention with .NET 5 is that each application only imports and uses the libraries it needs.  Each of these dependencies are far more granular than before, which means more dependencies listed, but a greater ability to pick and choose.   There are no XML APIs in the Core CLR, for example. 

In the previous .NET versions (1.0 through 4.6) all of the libraries were installed all the time (for the desktop/server versions, anyway).  A lot of ASP.NET functionality was encapsulated in the fearsome System.Web namespace, which had everything you could possibly need to build an ASP.NET application.   As the world moves to virtual servers in cloud environments, there is a real cost to stuffing all those unused libraries in memory.  The ability to slim down an application to only the bits needed is the right direction.

DNX – .NET Execution Environment

⇒Was called K or KRE in alpha and beta releases.

DNX contains the components required to run an ASP.NET 5 application.  The ASP.NET Github wiki describes DNX as an SDK containing everything needed to build and run an ASP.NET 5 application.   This includes the compilation and native CLR hosts – everything required to load up a .NET program and execute the instructions inside.

DNX is sort-of like the .NET installation of old, in that you can have more than one version installed at once.  This always had promise of overcoming DLL hell in prior Windows COM implementations but the reality was always somewhat dashed upon the rocks of the Global Application Cache (GAC).  What DNX does is provide completely separate installations that can be targeted by an application, and nothing is shared between them.

The above image shows two different versions of DNX installed on a Mac.   The ‘Roslyn’ compiler libraries have been renamed ‘CodeAnalysis’) and the K libraries have been replaced by the DNX libraries.   Like with the previous ‘K’ syntax, starting an application –whether console or website – is done with the ‘dnx’ syntax, which is dnx <something> <argument>.   Web applications are started with dnx web.  Console applications are started with dnx run.   This is done in the path of the application you wish to run, so the DNX paths are global to the computer, and each application is bound to a specific DNX version.

DNVM – .NET Version Manager

⇒Was called K Version Manager or KVM in alpha and beta releases.

DNVM is the tool used to maintain, install, upgrade and set specific versions of DNX on the computer.   As there can be multiple versions of DNX installed, DNVM is the tool used to assign a specific project to a specific DNX version.  With DNVM, you can install a specific DNX version from the feed and set an alias for a specific version.   You can also set the default version you want to work with on the computer.

One of the cool things about a lot of recent Microsoft work is the inclusion of ASCII art within the console applications, and DNVM is no exception.   In the above picture, you can see the dnvm list command, which has listed the available DNX versions installed – which matches the file listing image in the DNX section above.

DNVM doesn’t really have an equivalent in tradition ASP.NET – the only thing close was the aspnet_regiis.exe function which used to be used to set up ASP.NET to bind a specific version with a specific website.  But that comparison understates DNVM by a long way.

DNU – .NET Utilities

⇒Was called KPM or K Package Manager in alpha and beta releases.

The DNU library is located in the DNX folder, so this is version-specific to a DNX install.   DNU is used to manage the packages required by an application to run.   DNU is used to manage the dependencies in a .NET 5 application by installing or restoring the packages associated with a project (see project.json).   This can pull down new versions or repair versions that are not set up correctly.   Strictly speaking DNU is part of the overall DNX SDK.

DNU is kind-of equivalent to a mix of MSBuild with the Nuget command line package manager in Visual Studio – except that it’s complete separate from Visual Studio and much simpler to use (I’m referring here to MSBuild).  It’s a worthwhile concept and something that is easy to learn.

project.json

⇒No change from the ‘K’ versions – probably because it didn’t involve the letter ‘K’

The project.json file is the project file for an ASP.NET 5 project.   It’s important to understand that this is not a Visual Studio project file – this can be loaded by Visual Studio but is not dependent on it.   DNU reads the project.json file for the dependencies when retrieving and configuring the dependencies for the project.   The project.json file also determines the runtimes that can execute the project – the linked example shows Kestrel and Web – this is because it can be run on either a Mac (or Linux) box, and also on Windows.

So DNU reads the project.json file and installs the relevant packages to construct the project, and creates the runtime.  DNX executes the runtime based on the commands specified in the project.json file, and the choice of which DNX version is used is set by the DNVM.   It’s all pretty simple in practice even if it sounds a bit long winded.  The key takeaway is that all the settings and configurations are right there in the files where you can see them.  Not buried in some distant Regex setting that you never understand the relationship between the code with.

project.json is an evolution of the old Visual Studio project files and MSBuild files, as well as the assembly.cs files.   It combines it all together in a text file which is not tied to a specific VS version.  This is big, big progress for source-controlled applications with the ability to run in multiple runtime environments.

Kestrel

⇒No change from the ‘K’ versions.

Kestrel is a mono specific platform for executing ASP.NET 5 code.  It’s a small, lightweight web server designed for development use.  Note that an existing github project called ‘Kestrel’ was already around, so if you’re looking for information you’ll need to search on DNX specific terms.

MVC

MVC means more than just ‘MVC’ now.  Of course, it still means ‘Model View Controller’ but that is understating things somewhat.  MVC is now a catch-all term for the business of responding to requests and sending results.   This includes Web Pages (there are no Webforms in ASP.NET 5) and WebAPI.  This means there is a unified routing mechanism for URLs, and the response can be via a View or as Data as in WebAPI.

In prior ASP.NET versions, MVC referred specifically to the MVC implementation for delivering websites using the Model/View/Controller pattern.  WebAPI was developed as a separate way of delivery of API results, and the overlap meant it was sometimes hard to set up a clean application architecture.  This has all been resolved in ASP.NET 5.

MVC is officially MVC 6 in ASP.NET 5.

Summary of the DNX Terminology

With the bulk of the worlds production ASP.NET implementations running on anything from 1.0 to 4.6, it will be a while before the balance tips towards ASP.NET 5.   Breaking changes are always difficult to accept and conceptualize, particularly if your ‘day job’ means keeping both universes in your head.   There is little doubt that these changes are all positive and will create productivity benefits both for the development and – crucially – the runtime phases of applications.

To summarize everything in this post:

• DNVM installs and sets the DNX version for a specific project
• DNU retrieves the dependencies and builds the application as specified in the project.json file
• DNX runs the application by executing the runtime specified in the project.json