In this section, we will cover the basics of .NET Core 1.0 as a platform and the components involved in it.

The .NET Core 1.0 platform was reinvented for various reasons. The web stack of ASP.NET was pretty old and was started back in .NET Framework 1.0. ASP.NET was overweighed with a lot of old and unused code. Even the code it not used as it becomes unavoidable from loading them. The biggest one is System.Web, which is a linkage between the old ASP.NET and today's ASP.NET. MVC and Web API are trying to isolate themselves from System.Web.

Self-hosting of ASP.NET, MVC, and Web API is one of the objectives so that they can be hosted independently of the server platform. However, it was tied to the Windows platform on IIS. This becomes an issue when an application needs to be retested for any new bugs that were introduced due to the newer version of .NET when updated to servers as these depend on machine-level versions of .NET, and it is not possible to isolate the version of .NET from your application so that it can run independently of the newer version of .NET.

The ASP.NET team had decided to rewrite the code from the ground up as the time frame was vulnerable by the amount of code that had to be loaded in, compiled, written to disk, loaded back into memory, and then executed. For good, a lot of things have been changed in .NET Core 1.0, and it is incredibly different from every other version of ASP.NET. That's why it is good to call it with a new name and new version as it is not an incremental change.

A key difference is that .NET Core 1.0 is cross-platform and open source. .NET Core 1.0 is a single platform that combines both the concepts of MVC and Web API into one solid set of APIs and all the legacy code is gone. Everything is a dependency in .NET Core 1.0. We can develop a .NET application as small as we want it to be. Some parts of .NET Core are now a NuGet. So, you can load only the required assemblies from NuGet, and this leads to a small memory footprint compared to the previous versions of ASP.NET.

Multiple deployment support is possible today in .NET Core 1.0, and this enables us to deploy to clouds, such as Azure, AWS, and other cloud services. You can host it in IIS, or it can be self-hosted, which enables us to execute from the command line. .NET Core 1.0 supports true cross-platform, and it can be hosted on both Windows and OSX or Linux:

As shown in the preceding figure, .NET Core includes a new CLR that is supported on both OSX/Linux and Windows. ASP.NET can also run on top of Mono. Using the native IIS loader, we can load and host our applications in IIS. This native IIS loader routes requests directly to ASP.NET without the need to go through ISAPI filters and others. On the Windows platform, you can also self-host the application from the command line using a tool called dotnet.exe. .NET Core 1.0 also supports self-hosting on Linux and OSX and can be done using some sort of tool, such as dotnet.exe, so that the application can be run just with a command line.

The self-hosted solutions are similar to Node. Running Node and then the root of your application is very similar to the way that self-hosting works in .NET Core with the dotnet.exe tool. So, being cross-platform supported, the code you write will not necessarily care about where it's being hosted.

.NET Core is the new cross-platform and a subset of the .NET Framework. The .NET Core is meant to be as small as possible. The CoreCLR or .NET Core Framework is a subset of the .NET Framework. So, all functionalities will not be available in .NET Core. For example, sending a mail is achieved by the mail subsystem inside the .NET Framework in the System.Net namespace. However, this functionality doesn't exist, and it can be accomplished using some open source solutions.

The .NET Core team wanted to compose everything via NuGet packages. So, everything preceding the CLR and C# and VB compilers is a NuGet package. The .NET Core 1.0 is really the bootstrap and the CLR is not a whole. The code knows how to load up an application and get it started, and then the CLR actually manages the execution of that code. Everything else will be a NuGet package. MVC looks at static files doing logging, configuration, and identity; they're all just packages that can be added to a project. So, as you talk about creating thicker or thinner applications, you can make decisions about what to include in your project. Everything in ASP.NET is optional.

The ASP.NET 5 team has tried to embrace the Node package manager for different sorts of tooling support, using npm or Bower for client-side library support, using Grunt and Gulp for build automation, and NuGet for .NET packages.