Introduction to .NET Core
03 October 2016 | Software & Technology
What is .NET Core?
Since the appearance of .NET, from .NET Compact Framework to Silverlight, or from Windows Phone to other Windows Store applications, software developers had to deal with fragmented versions of .NET. Although all this versions should have had a so-called ‘’common’’ runtime, they each ended up being a different subset of .NET for each platform in the Microsoft Suite.
Figure 1 – .NET for each platform
Each of the existing versions has and will always have different capabilities, but having a common base for all of them instead of very well defined subsets would be a big plus. The fact that .NET supports desktop or mobile applications and lets us use components that can be perfectly integrated on any one of them, makes it an ever more attractive development environment. At the same time, it fixes a lot of versioning and compatibility problems emerged over time.
Without trying to replace the well-known .NET Framework, .NET Core brings a series of benefits, such as:
- it is open-source;
- it doesn’t require to be installed at machine level;
- it is small, fast, modular and expandable;
- it will be the first to receive updates / patches in the .NET environment;
- it is portable – depending on what the project targets, the code can run on Mono and Xamarin, on Windows 8 and Windows Phone and on the Universal Windows Platform (UWP);
- it can be deployed on Linux;
- it also can be deployed on a Docker host.
Also, it has a new configuration model for JSON based applications. .NET Core uses key-value pairs, thus eliminating the classic web.config.
The ASP.NET hosting model doesn’t consider the requests directly, but relies on a HTTP server implementation, which previews the interfaces that can be composed in an HttpContext. It includes support to run in the classic version in IIS or outside IIS (self-hosting) by using Kestrel – an open source web server, written with Libuv, a multi-platform library focused on the asynchronous operations I/O, which initially targeted Node.js.
Figure 2 – ASP.NET vs ASP.NET Core
ASP.NET Core is formed from a subset of libraries named ‘’CoreFX” and a small optimized runtime named ‘’CoreCLR”, distributed as individual packages through NuGet.
One of the major benefits brought by .NET Core is portability. CoreCLR can be packed and deployed together with the application, thus eliminating the dependency on the version that is installed on the server. Furthermore, hosting several applications simultaneously on the same server is possible, even if they target different framework versions. Therefore, you are no longer forced to upgrade all the applications at once.
Figure 3 – ASP.NET Core architecture
This is one of the main components of an ASP Core project, which replaces the web.config from the previous versions of .NET. It contains properties related to metadata (version, authors, compiling options) and dependencies (used by NuGet). It also allows on to specify build and publish options.
DNX (Dot Net Execution Environment) is an SDK and a runtime environment which includes all the necessary elements to build and run .NET applications for Windows, Mac and Linux. It was built to run ASP.NET cross-platform applications and it enables its users to target the complete version of ASP.NET, as well as the light one, represented by .NET Core.
DNX hosts the CLR, executes the application and is the entry point.
Dnx451 – is the complete version of .NET, which is installed along with Visual Studio.
DnxCore – is the version that operates cross-platform lightweight, with fewer features.
Middleware refers to reusable components written in separate classes and assembled in the pipeline of the application that manages requests and answers. It implements extension methods in Application Builder.
A classic ASP.NET Core application will have several middleware components configured, such as Static Files Middleware, Authentication Middleware or MVC.
Startup.cs replaces Global.asax. It has a Main method and other methods that are called by the DNX. Startup.cs is configured by the developer; essentially, it enables one to define the middleware components that will form the pipeline.
Xproj is a Visual Studio specific file used behind the scenes, which replaces the csproj together with project.json.
Packages from NuGet, NPM and Bower
We all know that NuGet is the main tool used by .NET developers to easily install various packages / libraries, either server-side or client-side.
Sometimes, the client-side packages require many dependencies and configurations and this can cause serious problems for the least experienced of us. In addition, the integration with Studio of the most common tools from the web development world hasn’t always been the easiest. Microsoft makes them an integrated part of the IDE and encourages their extensive use.
Figure 4 – Tools included in Visual Studio
.NET Core includes only the libraries and the minimal common functions absolutely necessary for an application to run cross-platform (Mac, Linux, Windows). In other words, you “pay” only for what you use. This can only make us happy, since tests showing that it supports with 2300% more requests per second than the ‘’old” ASP.NET 4.6. are already out there.
IrinaSenior software developer and Microsoft Certified Solution Developer for Web and Application Lifecycle Management. Above all, passionate about leadership and personal development, both hers and her team's.