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.
Conclusion
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.
Remember!
- 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.