Beginning with .NET Core

Talking about ASP.NET Core without explaining .NET Core is somewhat cumbersome. .NET Core is the framework everyone is talking about, and for good reasons. ASP.NET Core is probably the most interesting API right now, as it seems that everything is moving to the web.

And why is that? Well, all these APIs relied heavily on Windows-native features; in fact, Windows Forms was merely a wrapper around the Win32 API that has accompanied Windows since its early days. Because .NET Core is multiplatform, it would be a tremendous effort to have versions of these APIs for all supported platforms. But of course, in no way does this mean that it won't happen; it's just that it hasn't happened yet.

With .NET Core, a host machine only needs a relatively small bootstrap code to run an application; the app itself needs to include all the reference libraries that it needs to operate. Interestingly, it is possible to compile a .NET Core application to native format, thereby producing a machine-specific executable that includes in it all the dependencies, and can even be run in a machine without the .NET Core bootstrapper.

As I said previously, .NET Core was written from scratch, which unfortunately means that not all the APIs that we were used to have been ported. Specifically, as of version 3, the following features are still missing:

• ASP.NET Web Forms (System.Web.UI)
• XML Web Services (System.Web.Services)
• LINQ to SQL (System.Data.Linq)
• Windows Communication Foundation server-side classes (System.ServiceModel)
• Windows Workflow Foundation (System.Workflow and System.Activities)
• .NET Remoting (System.Runtime.Remoting)
• Active Directory/LDAP (System.DirectoryServices)
• Enterprise Services (System.EnterpriseServices)
• Email (System.Net.Mail)
• XML and XSD (System.Xml.XslandSystem.Xml.Schema)
• I/O ports (System.IO.Ports)
• Managed Addin Framework (System.Addin)
• Speech (System.Speech)
• Configuration (System.Configuration); this one was replaced with a new configuration API (Microsoft.Extensions.Configuration)
• Windows Management Instrumentation (System.Management)
• Windows Registry (Microsoft.Win32) in operating systems other than Windows

This is by no means an exhaustive list. As you can see, there are a lot of features missing. Still, it is quite possible to achieve pretty much whatever we need to, provided we do things in a different way and handle the extra burden! Mind you, Windows Forms and WPF are already supported on all platforms.

The following APIs are new or still around, and are safe to use:

• MVC and Web API (Microsoft.AspNetCore.Mvc)
• Entity Framework Core (Microsoft.EntityFrameworkCore)
• Roslyn for code generation and analysis (Microsoft.CodeAnalysis)
• All Azure APIs
• Managed Extensibility Framework (System.Composition)
• Text encoding/decoding and regular expression processing (System.Text)
• JSON serialization (System.Runtime.Serialization.Json)
• Low-level code generation (System.Reflection.Emit)
• Most of ADO.NET (System.Data, System.Data.Common, System.Data.SqlClient, and System.Data.SqlTypes)
• LINQ and Parallel LINQ (System.Linq)
• Collections, including concurrent (System.Collections, System.Collections.Generic, System.Collections.ObjectModel, System.Collections.Specialized, and System.Collections.Concurrent)
• Threading, inter-process communication, and task primitives (System.Threading)
• Input/output, compression, isolated storage, memory-mapped files, pipes (System.IO)
• XML (System.Xml)
• Windows Communication Foundation client-side classes (System.ServiceModel)
• Cryptography (System.Security.Cryptography)
• Platform Invoke and COM Interop (System.Runtime.InteropServices)
• Universal Windows Platform (Windows)
• Event Tracing for Windows (System.Diagnostics.Tracing)
• Data Annotations (System.ComponentModel.DataAnnotations)
• Networking, including HTTP (System.Net)
• Reflection (System.Reflection)
• Maths and numerics (System.Numerics)

• Reactive Extensions (System.Reactive)
• Globalization and localization (System.Globalization, System.Resources)
• Caching (including in-memory and Redis) (Microsoft.Extensions.Caching)
• Logging (Microsoft.Extensions.Logging)
• Configuration (Microsoft.Extensions.Configuration)

Again, this is not the full list, but you get the picture. These are just Microsoft APIs that are made available for .NET Core; there are obviously thousands of others from different vendors.

In .NET Core, there is no longer a Global Assembly Cache (GAC), but there is a centralized location (per user) for storing NuGet packages, called %HOMEPATH%.nugetpackages, which prevents you from having duplicated packages locally for all of your projects. .NET Core 2.0 introduced the runtime store, which is somewhat similar to GAC. Essentially, it is a folder on a local machine where some packages are made available and compiled for the machine's architecture. Packages stored there are never downloaded from NuGet; they are instead referenced locally and do not need to be included with your app. A welcome addition, I have to say! You can read more about metapackages and the runtime store at https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage.

As of ASP.NET Core 2.1, a change was made from the previous version: whereas before there was a dependency on the Microsoft.AspNetCore.All metapackage, now the dependency is on Microsoft.AspNetCore.App. To cut a long story short, this one has far fewer dependencies. Specifically, the following dependencies have been removed:

• Microsoft.Data.Sqlite
• Microsoft.Data.Sqlite.Core
• Microsoft.EntityFrameworkCore.Sqlite
• Microsoft.EntityFrameworkCore.Sqlite.Core
• Microsoft.Extensions.Caching.Redis
• Microsoft.AspNetCore.DataProtection.AzureStorage

• Microsoft.Extensions.Configuration.AzureKeyVault
• Microsoft.AspNetCore.DataProtection.AzureKeyVault
• Microsoft.AspNetCore.Identity.Service.AzureKeyVault
• Microsoft.AspNetCore.AzureKeyVault.HostingStartup
• Microsoft.AspNetCore.ApplicationInsights.HostingStartup

Visual Studio templates for .NET Core since version 3.0 already reference this new metapackage, and in general, things should just work; you may need to add explicit references to one of these missing packages, if you use it.

Interestingly, since version 3, you no longer need to reference this metapackage in your .csproj file; it is referenced by default when you reference the .NET Core 3 framework. The following is a minimum .NET Core 3 .csproj file:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>
</Project>

For .NET Core 3.1, you should replace netcoreapp3.0 with netcoreapp3.1. In a moment, we will learn more about this.

NuGet packages are at the heart of .NET Core, and mostly everything needs to be obtained from NuGet. Even projects in the same Visual Studio solution are referenced from one another as NuGet packages. When using .NET Core, you will need to explicitly add the NuGet packages that contain the functionality that you wish to use. It is likely that you may come across some of the following packages in some of your projects:

Again, this not an exhaustive list, but you get the picture. You may not see references to all of these packages, because adding one package that has dependencies will bring all these dependencies along, and big packages have a lot of dependencies.

There are no more .exe files; now, all assemblies are .dll, which means that they need to be run using the dotnet command-line utility. All .NET Core applications start with a static Main method, as the .NET Framework Console and Windows Forms did, but now we need the dotnet utility to run them. The dotnet tool is a very versatile tool, and can be used to build, run, deploy, and restore NuGet packages, execute unit tests, and create NuGet packages from a project. As I said, it is also possible to compile an assembly to the native format, but we won't be covering that here.

.NET Core ships with built-in DI, logging, and a flexible configuration framework, which allows you to plug in your own providers if you so wish. All of the new APIs (such as Entity Framework Core and ASP.NET Core) use these services uniformly. For the very first time, we can see a coherent behavior across APIs.

Also, most productivity APIs, such as ASP.NET and Entity Framework, allow you to replace the services they're built upon with customized versions, allowing you to make them work exactly the way you want them to—provided, of course, that you know what you are doing—and these services are generally based upon interfaces. Everything is much more modular and transparent.

Unit testing got first-class citizenship in .NET Core. Most new APIs were designed with testability in mind (think, for example, of the new in-memory provider for Entity Framework Core), and the tooling (dotnet) has an explicit option for executing unit tests, which can be written in any framework (currently, xUnit, NUnit, MbUnit, and MSTest, among others, have released unit test frameworks compatible with .NET Core). We will cover unit testing in Chapter 13, Understanding How Testing Works.

Next, let's look at the platforms that support .NET Core.

Supported platforms

.NET Core works on the following platforms:

• Windows 7 SP1 or higher
• Windows Server 2008 R2 SP1 or higher
• Red Hat Enterprise Linux 7.2 or higher
• Fedora 23 or higher
• Debian 8.2 or higher
• Ubuntu 14.04 LTS/16.04 LTS, or higher
• Linux Mint 17 or higher
• openSUSE 13.2 or higher
• CentOS 7.1 or higher
• Oracle Linux 7.1 or higher
• macOS X 10.11 or higher

This covers all modern Windows, Linux, and macOS distributions (Windows 7 SP1 was released in 2010). It may well work in other distributions, but these are the ones that have been thoroughly tested by Microsoft.

So, how does this work? It turns out that whenever you request a NuGet package that needs native libraries that are not included in the operating system, these are also included in the .nupkg archive. .NET Core uses Platform Invoke (P/Invoke) to call the operating-system-specific libraries. This means that you do not have to worry about the process to be located—adding a NuGet package and publishing the project is the same no matter what the target operating system will be.

Keep in mind that platform independence is transparent to you, the developer—unless, of course, you also happen to be a library author, in which case you may need to care about it.

Let's now see how the different frameworks that used to make up .NET are now supported.