Terms we don't fully understand while learning ASP.NET core

There are some terms, developers like me often ignore while learning ASP.NET Core. Because at the end of the day it's all about making apps not learning stuff. But having a basic understanding over the core concepts can make you a lot better developer than you already are. So, this article will clear the concepts of some of those ignored and misunderstood terms in details. This article is upgradable with new topics. So, if you have other topics such as below and want it here, please make a comment regarding those.

.NET Standard Library & .NET Standard

There are 3 primary .NET runtimes (CLR) (more on them in next topic) and all of them implements the .NET Standard Library (a set of BCL APIs). The .NET languages also run on any runtime. The .NET Standard Library is also a build target, where it is known as the .NET Standard. .NET Standard is a specification telling you that whether a set of APIs is available in a specific runtime. There are different version of .NET Standard ranging from 1.0 - 2.0. Here, version 1.0 contains the least number of APIs. Number of cumulative APIs grow with the version number. Notice the cumulative term used in the sentence. That means a .NET Standard version, say for example 1.6 contains all the APIs from 1.0 - 1.5 and its own sets of APIs.

.NET Framework & .NET Core

.NET framework, .NET Core and Mono for Xamarin are 3 primary runtimes. First two of them are used to write server-side applications using .NET. The following table is taken directly from Microsoft official documentation that shows what version of what runtime supports what .NET Standard version.

.NET Standard 1.0 1.1 1.2 1.3 1.4 1.5 1.6 2.0
.NET Core 1.0 1.0 1.0 1.0 1.0 1.0 1.0 2.0
.NET Framework (with tooling 1.0) 4.5 4.5 4.5.1 4.6 4.6.1 4.6.2
.NET Framework (with tooling 2.0 preview) 4.5 4.5 4.5.1 4.6 4.6.1 4.6.1 4.6.1 4.6.1
Mono 4.6 4.6 4.6 4.6 4.6 4.6 4.6 vNext
Xamarin.iOS 10.0 10.0 10.0 10.0 10.0 10.0 10.0 vNext
Xamarin.Android 7.0 7.0 7.0 7.0 7.0 7.0 7.0 vNext
Universal Windows Platform 10.0 10.0 10.0 10.0 10.0 vNext vNext vNext
Windows 8.0 8.0 8.1
Windows Phone 8.1 8.1 8.1
Windows Phone Silverlight 8.0

As you can see while .NET Core 2.0 supports .NET Standard 2.0, .NET Framework (with tooling 1.0) 4.6.2 only supports .NET Standard 1.5. Again, .NET Framework (with tooling 2.0 preview) supports .NET Standard 2.0 but Windows Phone Silverlight (8.0) has only support for .NET Standard 1.0. So, what does it mean actually? It means that, code written in Windows Phone Silverlight (8.0) platform can also run in .NET Core, .NET Framework (with tooling 1.0) and .NET Framework (with tooling 2.0 preview) because they all supports .NET Standard 1.0. On the other hand, code written using .NET Framework (with tooling 1.0) (4.6.2) that supports .NET Standard 1.5 can't run on Windows Phone Silverlight (8.0) because it only supports Net Standard 1.0.

.NET Core is a new boy in town. It is cross platform. You should use it when you are targeting microservices and want to use docker containers.

.NET Framework has been in the business since 2002. If you are building applications that only run on Windows PCs, devices and servers then choose .NET Framework. Many third-party .NET libraries or NuGet packages is not available for .NET Core, in that scenarios you should use .NET Framework.

Other than that, you should port your code written in .NET Framework to .NET Core.


ASP.NET is a 15 years old technology that is still being used to build web application and it is based on .NET Framework. It is heavily coupled with the System.Web.dll which makes it impossible to decouple a web application from its web server. Means that you can only host an ASP.NET application in an environment which also supports .NET Framework. In this case IIS would be the only hosting environment where an ASP.NET application can be hosted.


To overcome this problem of server and application coupling, Owin (Open Web Interface for .NET) comes up with a specification. It's an open standard saying that how a server and an application should be decoupled from each other and talk through a common interface. When we talk about decoupling we can think about plug and unplug stuff by staying true to the abstraction. So, you can think about combinations of different OWIN based server implementations (like Katana, NOWIN) and application frameworks (like SignalR, Web API, Nancy).


ASP.NET Core is the complete redone of the ASP.NET framework where unnecessary code that have been dragged over with .NET Framework for last 15 years is removed. That means you only import something that you actually need and nothing more than that. And that is when the term true versioning of the framework came in. However, that doesn't mean that you can only use stuff that are available in .NET Core framework. Because that would be silly since all the Nuget packages that have been developed over the years using .NET Framework would be useless. So, when you are developing in Windows environment you can have the best of both worlds if you want.

ASP.NET Core applications can be hosted on top of OWIN based server/host. And other OWIN based components can be run on top of ASP.NET Core. That's it and nothing more. It's not like the ASP.NET Core framework has been built on OWIN. Servers implementation provided by ASP.NET Core such as Kestrel & WebListner are OWIN compatible.


ASP.NET Core needs a host to execute. Don't mix up a host with a server. Host is responsible for application startup and its lifetime management. ASP.NET Core uses a WebHostBuilder which returns an instance of a WebHost, that of course implements the IWebHost interface. While a host references an implementation of a server, the server is totally unaware of its host.


A host requires a server for listening to HTTP requests. ASP.NET Core has two server implementations namely Kestrel and WebListener. Both of them implements the IServer interface. You can configure one of these two servers for your host. The main task of a server is to accept incoming requests and present them to the application in form of an HttpContext. Typically, you would want to use IIS/Apache/Nginx as a reverse proxy server which will accept request from the web and delegate them to Kestrel after some preliminary handling. Notice that I only mentioned Kestrel, since WebListener cannot be run inside IIS. While Kestrel is a cross platform web server, WebListener only works in Windows platform and it doesn't need IIS.

However, if you wish to run an ASP.NET Core application with Kestrel behind IIS, you have to configure the ASP.NET Core Module. It's a native IIS module that helps IIS communicate back and forth with Kestrel. So, why an additional server? That is because while Kestrel being a fast server it doesn't provide all the features that IIS provides. Features such as Security, Load Balancing, Port Sharing etc.


A Middleware is a piece of software that sits in the application pipeline for handling requests and responses. The idea is to pass a request (HttpContext) through it where the request is being processed. The middleware itself decides whether to pass the processed request to the next middleware(s) in the pipeline or terminate them altogether. In ASP.NET Core Middleware(s) are actually request delegates. The ordering of the request delegates are very important. For example, a middleware setup for handling MVC routing before a middleware that handles static files can cause weird behaviors such as not finding a file with an extension in the wwwroot folder.


Services include third-party package components and your own application components, which need to be injected around throughout the application. These services can be exposed with the build-in/third-party dependency injection containers. Like for an example, if you want to inject around Entity Framework's DBContext as a service throughout your application, you must expose it through some sort of dependency injection container. That enables you to write code against abstraction rather than concrete types. Means that you would basically use an interface of a specific service where it is needed and pass the implementation of it via a dependency injection container.

ASP.NET Core has its own sets of built-in services such as,

  • IHostingEnvironment, a service that is used to get access to current hosting environment related information.
  • ILogger, a service for doing logging in parts of an application where needed.