CheapASPNETHostingReview.com | Best and cheap ASP.NET Core 2.0 hosting. At Build 2017, there were a lot of new features announced for ASP.NET Core 2.0, .NET Core 2.0 and .NET Standard 2.0.

Today, we’re going to look at a few of the changes, specifically: the new configuration model and Razor Pages

Configuration

A lot of the changes that the ASP.NET Core team have brought to ASP.NET Core 2.0 are all about taking the basic application setup and making it as automatic, and quick and easy to change as possible. The first and easiest way that they have done this is by creating the AspNetCore.All package.

AspNetCore.All Package

In previous versions of ASP.NET Core when we’ve created an application and wanted to add in functionality, we’ve had to search on NuGet or using the Package Manager to find the NuGet packages for the functionality that we want.

This lead to a csproj which looks like this:

Re-targeting this project as a netcoreapp2.0 (.NET Core 2.0) application with ASP.NET Core 2.0 libraries, we get the following csproj file:

The AspNetCore.All package is a meta package which pulls down all of the relevant (Anti Forgery, Auth, Entity Framework Core, MVC, Static files, etc.) packages to our application when package restore happens.

Because we no longer have to track down each of these individual packages, our job is made easier. Also, when the packages within the AspNetCore.All package are updated, the updated versions will be included in the AspNetCore.All meta package.

The AspNetCore.All package is included in .NET Core 2.0’s Runtime Store, and is compiled to native code, rather than IL. This means that all of the libraries included in the AspNetCore.All package are pre-compiled as native binaries for the Operating Systems that .NET Core 2.0 supports.

Boot Time Improvements

Dan and Scott were able to show that ASP.NET Core 2.0 applications can cold boot in less than a second, versus up to 7 seconds for ASP.NET Core 1.0 applications.

The ASP.NET Core team have achieved this by shipping the AspNetCore.All package in native code for each platform, and by enabling view pre-compilation. By pre-compiling the views, they no longer have to be compiled at start up.

View pre-compilation is a trick that has been around in .NET Framework for a while, but it isn’t a default build action.

New Program Setup

This leads me nicely onto the new program setup model.

In ASP.NET Core 1.0 the program.cs file contained a single method for configuring and running the server, and there was a lot of manual configuration required. As in the following code block:

To enable server features, you had to know what those features where called or rely on intellisense in order to find the right methods.

But in ASP.NET Core 2.0, a lot of the configuration is taken care of for us. So much so that the following code snippet is the default program.cs for an ASP.NET Core 2.0 application:

From the off, you can see how much simpler the new program.cs file is. The new program.cs goes hand in hand with the new startup.cs

First a refresher on what the ASP.NET Core 1.0 startup.cs:

Configuration is handled by us developers and we have to explicitly list all configuration files and enable logging.

Compare this to the new startup.cs:

There’s a lot that’s changed here, so let’s look at the changes in turn.

The Constructor and DI

Taking a look at the constructor, we can see that the configuration is Dependency Injected in for us.

This is because all of the explicit configuration that we had to do in ASP.NET Core 1.0 is done automatically for us. ASP.NET Core 1.0 will look for any and all relevant json/ini files and attempt to deserialise them to objects for us and inject them into the IConfiguration object.

The ConfigureServices method is pretty much the same, but the Configure method has been very simplified:

In the ASP.NET Core 1.0 Configure method, we had to inject the ILoggerFactory in order to enable logging:

However, the ASP.NET Core 2.0 Configure method doesn’t have the ILoggerFactory injected in:

This is because the contents of the appsettings.json are parsed and added into the IConfiguration object which is injected in at the constructor level of the class:

If we take a look at the appsettings.json, we can see that the logging is set up for us there:

And looking at the highlighted lines, we’ll see that logging is set up so that we’ll only get warnings. This can be proven by running the application from the terminal. Doing so, and navigating around in the application, you won’t receive any messages in the terminal other than warnings:

However, if we edit the appsettings.json file to match the following:

Then re-run the application and click around, we’ll see the familiar log messages again:

Its entirely up to the developer and their needs as to which level of logging they require. I prefer information logging when I’m developing and to switch to warnings once I’ve published, but your requirements may be different.

Razor Pages

The other big new thing in ASP.NET Core 2.0 is the concept of Razor Pages. Razor Pages are enabled by default, as they are a feature of MVC, thus the following line in the startup.cs enables them:

Razor Pages cover the situations when creating a full blown Controller, View and a Model for a single or small number of pages seem a little over kill. Take for instance a simple homepage with no controller required, presumably something which could be handled by a static page, but which should have a simple model.

An example of this can be seen in the ASP.NET Core Web App (Razor Pages) template, which is installed as part of the .NET Core 2.0 preview1:

Taking a look at the directory structure for this new template, we can see that the new Razor Pages are located within the Pages directory.

Routing

Before we take a look at the contents of one of the Razor Pages, it will be worth covering how the routing for Razor Pages works. The request URL for a Razor Page is mapped to it’s path within the Pages directory – the Pages directory being the default location which the Runtime checks for any Razor Pages which could match the requested URL.

The following table shows a few examples of how the location of Razor Pages maps to requests: