The .NET Core Framework and Execution Environment
Microsoft continues to evolve the .NET Framework; in doing so, it is now tackling the significant issue of the full framework being required (and installed machine wide) to get your applications to run properly. This has presented many problems over the years. For one, to take advantage of a new framework’s features, you needed to upgrade the entire machine and thus anything else on that machine that relied on the .NET Framework. You also did not have a choice in the amount of the framework you wanted to use; instead, it was all or nothing. This added unnecessary overhead (and sometimes performance hits) to your application. With the latest version, the .NET Framework has answers for these dilemmas. It is moving from a single, machine-wide framework for all Windows programming to a framework that can be specialized (and optimized) to an application’s needs. The following outlines the versions of the framework available to ASP.NET developers:
.NET Framework—This is the full version of the .NET Framework that we have all been using to-date. It runs on Windows; it supports all existing applications without modification, and it includes ASP.NET. You can write ASP.NET 5 applications that target the full, NET Framework (version 4.6 at current release). This is also the default runtime for nearly all new projects created in Visual Studio.
.NET Core Framework—This is the new, modular, cloud-optimized version of the framework and CLR runtime. This is referred to as .NET Core 5. Developers can pick and choose only the components and features (packages) on which their application depends. You do so using the familiar NuGet package manager. You can then ship those features along with your application (instead of requiring a full machine install). This provides a couple advantages: you can run various versions of .NET Core 5 and the .NET Framework side by side on a single machine; and, individual components of the .NET Core can be upgraded, installed, and used separately without requiring a full revision of the framework (or patching on the server).
The .NET Core consists of a subset of .NET libraries called CoreFX. It also includes an optimized runtime called CoreCLR. The CoreFX libraries can be installed as individual NuGet packages (as System.[module]).
The .NET Core has a much smaller footprint (11 MB instead of nearly 200), and its memory requirements are also much smaller. It has been specifically optimized for running ASP.NET applications in the cloud by requiring lower memory consumption and higher throughput.
.NET Core 5 on other platforms—Microsoft is also releasing the .NET Core 5 framework for both Linux and Mac OS X. This gives developers the ability to develop and execute .NET applications on these platforms. Microsoft has worked with the Mono community to develop these versions of the framework.
The .NET Execution Environment (DNX)
Microsoft has created the .NET Execution Environment (DNX) to bundle versions of the framework, the CLR, and an SDK to provide the necessary bits to build and execute ASP.NET applications on Windows, Mac, and Linux. DNX simplifies the packaging of these items. It also allows you to build on one platform and run the application on another platform, provided you are using the same DNX version.
Upcoming sections will examine targeting various versions of the framework and runtime using DNX while developing, debugging, and releasing code. We will also cover using NuGet to select the right modular framework packages for your application.
Porting Existing Web Apps
Your web applications built on prior versions of ASP.NET including Web Forms, Web API 2, MVC 5, Entity Framework 6, Web Pages 3, and so on will all still work in Visual Studio 2015 and the latest version of the .NET Framework, without modification. Of course, you likely will have to use the full .NET Framework (and not the new .NET Core Framework) because it maintains backward compatibility.
You can, of course, take advantage of the newer features of ASP.NET 5 and the Core Framework with your existing sites. To do so, you will need to port your applications to the new framework. Porting does not mean rewriting; it typically only involves fixing specific issues in the app.