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
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.5 and its own sets of APIs.
.NET Framework & .NET Core
.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 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|
|Universal Windows Platform||10.0||10.0||10.0||10.0||10.0||vNext||vNext||vNext|
|Windows Phone Silverlight||8.0|
As you can see while
.NET Core 2.0 supports
.NET Framework (with tooling 1.0) 4.6.2 only supports
.NET Framework (with tooling 2.0 preview) supports
Windows Phone Silverlight (8.0) has only support for
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 Framework (with tooling 1.0) and
.NET Framework (with tooling 2.0 preview) because they all supports
1.0. On the other hand, code written using
.NET Framework (with tooling 1.0) (4.6.2) that supports
1.5 can't run on
Windows Phone Silverlight (8.0) because it only supports
.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
.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
Other than that, you should port your code written in
.NET Framework to
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
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.
host requires a server for listening to
ASP.NET Core has two server implementations namely
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
WebListener cannot be run inside
Kestrel is a cross platform web server,
WebListener only works in
Windows platform and it doesn't need
However, if you wish to run an
ASP.NET Core application with
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
Port Sharing etc.
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
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
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.