ASP.NET Core 3 exists in an ecosystem where everything else is changing as well, including the .NET Core runtime, which is currently at version 3 as well, and the C# language itself, which is at version 8. With all of these changes, ASP.NET Core has been adapting to the ecosystem changes as well, not only to Microsoft-related changes but also taking into consideration the developer community in general, as evidenced by, for example, changing the Angular template to Angular 7.

The ASP.NET Core 3 shared framework has been made significantly more lightweight, being decoupled from other non-core components such as Entity Framework Core, Roslyn code analysis, and Json.NET.

Changes such as these have inevitably effected other changes in a ripple effect, for example, in the forced removal of runtime compilation, which is obviously made possible by Roslyn, and as such, ASP.NET Core 3 is significantly more lightweight than its predecessors.

ASP.NET Core evolved from being referenced as packages in 1.0 into being a shared framework in 2.1. However, in 3, we no longer reference Microsoft.AspNetCore.App through the <PackageReference> element, which is naturally replaced as <FrameworkReference>.

If your project references the Microsoft.NET.Sdk.Web SDK, then it automatically has access to the shared framework. Commonly referenced APIs such as MVC, Razor, and Kestrel, among others, are no longer referenced as NuGet packages but are still available to us as developers through the same <FrameworkReference> element to Microsoft.AspNetCore.App.

ASP.NET Core 3 has attempted to improve integration with OpenAPI and has introduced a system for generating API clients that integrate easily with NSwag and other code generators.

The following screenshot shows some of the new templates introduced from ASP.NET Core version 3:

One of the biggest introductions to ASP.NET Core 3 is the C# Razor components, which has, to date, been known as Blazor. It was being developed separately as an independent experimental framework, and with it comes a new .razor extension that helps the compiler to identify a file with Razor components.

Normally, JavaScript code is what most browsers have been able to understand and execute, but what Razor components bring to the table is the ability to be able to run C# in the browser. We will talk a bit more about Razor components in Chapter 6, Introducing Razor Components and SignalR.

ASP.NET Core 3 comes with a Worker Service template by default. If you're coming from a desktop development background, you will be familiar with Windows Services, and similarly daemons for those with Linux experience, and as an answer for the web environment, ASP.NET Core 3 has introduced a template for us to be able to develop worker services to cater for long-running services.

Another exciting new feature added with ASP.NET Core 3 is the gRPC Service template, which is going to be popular with developers who use microservices often. gRPC originated from Google and uses a bit more lightweight protocol buffer serialization compared to the common XML/JSON serialization in service-to-service communication over HTTP/2. A demonstration of this will be included in Chapter 8, Creating Web API Applications.

There have been significant improvements to the routing model as previous users of ASP.NET MVC will know, mainly with how it operates with middleware, aptly referred to as endpoint routing; it was introduced in 2.2 but specifically introduced in 3 is SignalR and Razor component integration with endpoint routing. More about this will be covered in Chapter 6, Introducing Razor Components and SignalR.

Now that we have seen many important features associated with ASP.NET Core 3, there is one feature that deserves a special mention and specific coverage, because of its significance. In today's diverse technological platforms, it is hugely important to support different platforms, and therefore we will look at how ASP.NET Core 3 is geared up for cross-platform support in the next section.