DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

What are K, KRE, KVM, KPM, Kestrel and other ASP.NET components?

UPDATE: Microsoft has renamed the terminology discussed in this post.  For the updated terminology, see DNX, DNVM, DNU and other ASP.NET 5 Terminology

In my last post  I introduced 7 things about vNext that ASP.NET developers needed to know.  This post will dig deeper into the pile of new terminologies and concepts and connect those to existing ASP.NET models and components where possible.  Where there is no logical mapping between something new and existing ASP.NET components, I’ll describe the new terminology and tools.  The objective will be that you end up more knowledgeable by the end of the post – unless you’re cheating and already know all these terms and are just trying to catch me out making a mistake.  Let’s dig in!

A re-introduction of ASP.NET vNext

ASP.NET vNext is a major release of the .NET based web development model which departs from the prior models significantly.  Understanding the new terminology is best commenced by understanding what has changed and why.  The ‘Why’ leads us to understand the purpose behind new components.

Whether you currently sling Webforms or flick out MVC Views, you’re presently writing code deeply, deeply intertwined with IIS.   I know this to be true without even looking at your code because you’ve never considered running it on anything other than a Windows Server running IIS.  That’s because the Http pipeline and the omni-present System.Web namespace are linked deeply into IIS.

ASP.NET vNext breaks up this conglomerate of web handling code and discards the requirement to have System.Web at the top of each code file.  If you’ve done work with SignalR or WebAPI you’ve already experience life outside the System.Web sphere.  This has now extended out to all aspects, which is why WebForms doesn’t exist in the new Core CLR, because neither does System.Web with which it depends.

The Core CLR, as you’ll recall, is a cut-down, lighter weight .NET vNext framework optimized for running in Windows based cloud based environments and on other platforms via Mono.  Jettisoning the IIS dependent code is the key behind these new capabilities.  Those new capabilities are going to be the focus of the remainder of the post.

K Everywhere

The first time I heard about what would become known to be vNext (which in turn will be known as ASP.NET 5), it was called Project K and mentioned in hushed tones.  I didn’t realize at the time that it wasn’t just a project codeword – the letter K pops up repeatedly.  Maybe it wasn’t intended that way, but with the public visibility of the now-open source code, it’s inevitable that codewords become production words.  I’ve read that ‘K’ comes from Project Katana but I’ll need someone to confirm that one for me before I go repeating it.

ASP.NET vNext Terminology Definitions

K Runtime or K Runtime Environment or KRE : The components required to run an ASP.NET vNext application.  It includes the compilation components and the native CLR hosts – everything needed to load up a .NET program and run it.

Now if you’re like me you always want to identify the exact files that belong to something.  So the above picture is an actual KRE installed on my Apple Mac.  That’s right, a KRE doesn’t have to be on Windows.  And also note I referred to the KRE in plural – because more than one can exists, even side by side on the same machine.  Note that the version of the install is stamped into the folder name.  That is because nothing goes into the Global Application Cache (GAC).  The GAC is singular, KRE is plural.

Other items of interest in the KRE folder is the Microsoft.Framework.Runtime.Roslyn dll files, and the Microsoft.Net.Http.Client.dll file, as well as the CSharp Code Analysis components.  As noted, the KRE is the components required to load up, compile and run an ASP.NET application.  Roslyn is the compiler, the Framework.Runtime files are the runtime, and the Http.Client file handles the requests.

You may also see ‘KLR’ mentioned – it doesn’t seem to come up much, but generally take it to mean the same as ‘K’ in general.

To run applications with vNext, you invariably type k <something> <argument> – it’s your entry point into running applications.  Start your web application with k web.  A console application is started with k run.

K equivalent in earlier .NET versions : There really isn’t an equivalent to the KRE for earlier versions of ASP.NET.  This is because it was installed as a monolithic application onto the machine itself.  I suppose you could say the entire .NET install was similar to K.  Someone would probably quibble with that definition, so lets move on.

K Package Manager or kpm: If you’re a keen spotter you’ll also note in the KRE folder the kpm file.  The kpm is used to manage the packages needed by an application to run.  This runs the imports to pull in the various components to build an application.  They are called packages because they are Nuget packages. 

With the kpm you can build a project, pull down the correct versions of packages referenced in your project and do other functions like listing the package dependencies.

Above : Showing kpm in use restoring packages referenced in a project.  Highlighted are the kpm command (which simply emits the options) and kpm restore, which pulls down the packages from Nuget.

KPM equivalent in earlier .NET versions : You could make the case that it’s a bit like a mix of MSBuild with Nuget.  Only in purpose, not in execution.  It’s a new concept, and a cool one at that.

K Version Manager or kvm :  The K Version Manager (kvm) is a tool used to install, upgrade, and maintain specific K versions in the local machine.  As you can have multiple KRE versions installed, kvm is the way to manage these.

As you can see in the above image, the kvm options are all about installing a particular KRE version, and managing that for use within a specific project.

kvm equivalent in earlier versions of .NET : In a way, it’s kind of similar to the old aspnet_regiis tool that came part of an ASP.NET installation.  With that tool, you could control the version of .NET that your IIS install was using.  But it’s only a rough comparison because the central tenet isn’t the same-  one is about setting the version on a central IIS install, the other is about managing the version on individual projects.  Again the analogy is weak but should be a useful point of entry for understanding.

project.json :  As I outlined in my 7 vNext Facts post, there isn’t a myriad of project types for ASP.NET.  There’s just one – and it’s very simple.  It’s a bunch of  code in a folder (did I just coin an acronym – BOCIAF?  Let’s run with bo-key-aff as the pronunciation)   Because there is no mandated Visual Studio trickery, you can then edit the code in the editor of your choice.  It’s all very simple.  Tying all that code into a coherent ASP.NET application is the project.json file.  It’s the file that determines the dependencies, version and other project-related information.

You’ll see in the above image that it’s in JSON format as the extension implies.  This replaces the xml based format of prior *proj files of earlier .NET versions.   The example lists the dependencies and the commands to run the project, and which frameworks it relies on.

The dependencies are what is read by the kpm in order to bring down the correct Nuget packages to construct the entire project.   So the kpm reads the project.json file and produces the runtime for the KRE to execute, and specifies which commands are supported by the KRE.  The KRE running the application was set for the project by the kvm.  Simple!

Project.json equivalent in earlier ASP.NET versions : This one is much easier to conceptualize.  It replaces the .csproj and .vbproj files in ASP.NET projects, with also elements of other VS-specific file like the assembly.cs files.  I much prefer this format as it is much easier to edit and will be far simpler to control and observe through change control tools.

Kestrel : Sticking with the ‘K’ theme, Kestrel is the development web server tool used for local development.  It’s not intended to be a replacement for IIS but is a way of running your code locally.

Kestrel equivalent in older versions of ASP.NET : Cassini was a small, development focused web server that has been used for local development.  Kestrel fills in that role currently.  It’s not clear if it will remain a development server or will grow into something you could use in Production.  Time will tell.


On the first approach to ASP.NET vNext, the strangely alien terminology can be quite baffling and confusing.  After breaking it down and understanding each piece, it’s really quite simple to understand and it all makes logical sense.  Even if the naming doesn’t.   Just learn the letter K and all the variants and you’ll be on the way.


  • kvm installs and sets the KRE version which hosts k for your project, which is what makes it run
  • kpm reads the project.json file and brings in dependencies and builds the code using the compiler in the KRE
  • Your code then runs on k using something like kestrel to execute the code

In the introduction I boldly stated that you will know more by the time you got to the end of this post.  I hope that has turned out to be true.  Unless you were trying to catch me out and find a factual error.   If you’re a resident of either the gotcha! camp or the mildly enlightened camp, you can leave your thoughts in the comments.  If you want a definition on another term you’ve come across – now’s the time to bring that up as well.


Jonathan Sheely
This post will need to be updated. All of those K commands have been re-branded to DNX ( aka. .NET Executable)

dnx - Replaces both k and kre.
dnvm - Switches your CLR.
nuget - Replaces knpm.
kestrel - I think this will still survive as the cross platform web server

Jonathan Sheely Friday, April 10, 2015 10:13 AM (link)
Daniel Mettler
Sound a lot like MS is learning lessons from nodjs, npm and grunt. Do you know if there is a grunt equivalent as well? or maybe even a compatible thing? Would be nice to use for uglifying etc. all in one go - or do you think it will be mixed and we'll use both?
Daniel Mettler Tuesday, April 14, 2015 9:48 AM (link)
Bruce Chapman
@Jonathan - that's true but I haven't seen the new naming really catch on yet where it matters - in blogs and places like stack overflow where it is discussed. What is interesting is that an increased emphasis on open source also decreases the ability for MS to impose one of it's arbitrary name changes. Sure, they hold the keys and control the conversation to some extent, and the github project names have changed. We'll see. I posted this because I've been playing with beta code, and this is exactly what I've been using. When it changes to release mode and we're all instructed to go through yet-another-arbitrary-ms-name-change that will give me the opportunity for another blog post!

@Daniel - there really isn't any reason for MS to create a grunt equivalent. The beauty of the new project format (which is just a folder full of files - BOCIAF in my acronym!) is that you can include Grunt artefacts with no real impact. In fact Scott Hanselman posted about Grunt tools for Visual Studio last year. There's no need to MS to re-invent that wheel when the entire focus is changing towards being a part of emergent web development trends instead of trying to set their own proprietary trend.
Bruce Chapman Tuesday, April 14, 2015 8:12 PM (link)
cathal connolly
Jonathan's correct about the name changes, though they're still percolating out - here's the link to the correct point on the video where this changed - https://www.youtube.com/watch?feature=player_detailpage&v=-qt0POsiAF8#t=128
cathal connolly Wednesday, April 15, 2015 9:32 AM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (32)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (209)
Chris Paterra (55)
Clinton Patterson (40)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (154)
Dave Buckner (2)
David Poindexter (4)
David Rodriguez (3)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (10)
George Alatrash (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (165)
William Severance (5)

Content Layout

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  

Copyright 2017 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out