What is the ModelState?

In short, the ModelState is a collection of name and value pairs that are submitted to the server during a POST. It also contains error messages about each name-value pair, if any are found.

ModelState is a property of a Controller instance, and can be accessed from any class that inherits from Microsoft.AspNetCore.Mvc.Controller.

The ModelState has two purposes: to store and submit POSTed name-value pairs, and to store the validation errors associated with each value.

All right, enough of the boring explanation. It’s code time!

The Sample Project

You can use sample project on Github.

Setup

Let’s start writing the code we need to demonstrate how the ModelState works in ASP.NET 5 MVC. We will begin by creating a straightforward view model, AddMovieVM:

namespace ModelStateCoreDemo.ViewModels
{
    public class AddMovieVM
    {
        public string Title { get; set; }
        public DateTime ReleaseDate { get; set; }
        public int RuntimeMinutes { get; set; }
    }
}

We will also create a corresponding Add.cshtml view in the folder Views/Movie:

@model ModelStateCoreDemo.ViewModels.AddMovieVM

<h2>Add Movie</h2>

<form asp-action="AddPost" asp-controller="Movie" method="post">
    <div>
        <div>
            <label asp-for="Title"></label>
            <input type="text" asp-for="Title" />
        </div>
        <div>
            <label asp-for="Description"></label>
            <input type="text" asp-for="Description" />
        </div>
        <div>
            <label asp-for="ReleaseDate"></label>
            <input type="date" asp-for="ReleaseDate" />
        </div>
        <div>
            <label asp-for="RuntimeMinutes"></label>
            <input type="number" asp-for="RuntimeMinutes" />
        </div>
        <div>
            <input type="submit" value="Save" />
        </div>
    </div>
</form> 

Lastly, we create a MovieController class with two actions:

using Microsoft.AspNetCore.Mvc;
using ModelStateCoreDemo.ViewModels;

public class MovieController : Controller
{
    [HttpGet("movies/add")]
    public IActionResult Add()
    {
        AddMovieVM model = new AddMovieVM();
        return View(model);
    }

    [HttpPost("movies/add/post")]
    public IActionResult AddPost(AddMovieVM model)
    {
        if(!ModelState.IsValid)
        {
            return View("Add", model);
        }

        return RedirectToAction("Index");
    }
}

When we submit our Add form to the POST action, all of the values we entered on the view will show up in the correct properties in the AddMovieVM instance. But how did they get there?

Peeking Into the ModelState

Let’s take a peek at the rendered HTML for the Add page:

<h2>Add Movie</h2>

<form method="post" action="/movies/add">
    <div>
        <div>
            <label for="Title">Title</label>
            <input type="text" 
                   id="Title" 
                   name="Title" 
                   value="">
        </div>
        <div>
            <label for="ReleaseDate">ReleaseDate</label>
            <input type="date" 
                   id="ReleaseDate" 
                   name="ReleaseDate" 
                   value="0001-01-01">
        </div>
        <div>
            <label for="RuntimeMinutes">RuntimeMinutes</label>
            <input type="number" 
                   id="RuntimeMinutes" 
                   name="RuntimeMinutes" 
                   value="0">
        </div>
        <div>
            <input type="submit" value="Save">
        </div>
    </div>
</form> 

When this page is POSTed to the server, all values in <input> tags will be submitted as name-value pairs.

At the point when ASP.NET 5 MVC receives a POST action, it takes all of the name-value pairs and adds them as individual instances of ModelStateEntry to an instance of ModelStateDictionary. Both ModelStateEntry and ModelStateDictionary have pages in Microsoft’s documentation.

In Visual Studio, we can use the Locals window to show what exactly this looks like:

We can see from the Values property of the ModelState that there are three name-value pairs: one each for Title, ReleaseDate, and RuntimeMinutes.

Each of the items in the results for the Values is of type ModelStateEntry. But what exactly is this?

What’s In the ModelStateEntry?

Here’s what those same input values look like, taken from the same debugger session.

You can see that each ModelStateEntry contains properties like RawValue, which holds the raw value that was submitted, and Key, which holds the name of said value. ASP.NET 5 MVC creates all of these instances for us automatically when we submit a POST action that has associated data. ASP.NET 5 MVC is therefore making what was a complicated set of data into easier-to-use instances.

There are two important functions of the ModelState that we still need to discuss: errors and validation.

Validation Errors in the ModelState

Let’s make a quick modification to our AddMovieVM class so that we are now implementing validation on its fields.

public class AddMovieVM
{
    [Required(ErrorMessage = "The Title cannot be blank.")]
    [DisplayName("Title: ")]
    public string Title { get; set; }

    [DisplayName("Release Date: ")]
    public DateTime ReleaseDate { get; set; }

    [Required(ErrorMessage = "The Runtime Minutes cannot be blank.")]
    [Range(1, int.MaxValue, 
           ErrorMessage = "The Runtime Minutes must be greater than 0.")]
    [DisplayName("Runtime Minutes: ")]
    public int RuntimeMinutes { get; set; }
}

We have added validation to these fields using the [Required] and [Range] validation attributes, as well as specifying the name to use in <label> tags with the [DisplayName] attribute. If the Title, the Description, or the RuntimeMinutes field fails validation, we need to show an error message.

To do that, we must make some changes to our view; we will need to add a <span> tag with the property asp-validation-for set for each input:

@model ModelStateCoreDemo.ViewModels.AddMovieVM

<h2>Add Movie</h2>

<form asp-action="AddPost" asp-controller="Movie" method="post">
    <div>
        <div>
            <label asp-for="Title"></label>
            <input type="text" asp-for="Title"/>
            <span asp-validation-for="Title"></span>
        </div>
        <div>
            <label asp-for="ReleaseDate"></label>
            <input type="date" asp-for="ReleaseDate" />
            <span asp-validation-for="ReleaseDate"></span>
        </div>
        <div>
            <label asp-for="RuntimeMinutes"></label>
            <input type="number" asp-for="RuntimeMinutes" />
            <span asp-validation-for="RuntimeMinutes"></span>
        </div>
        <div>
            <input type="submit" value="Save"/>
        </div>
    </div>
</form> 

The asp-validation-for property will render the validation errors message in the specified <span> element, with some default CSS already applied.

Let’s take a look at what happens to our collection of ModelStateEntry instances when an invalid object is submitted to the server:

Note that the IsValid property of the ModelState is now false, and the ValidationState property of the invalid ModelStateEntry instances is now Invalid.

When ASP.NET 5 MVC creates the model state for the submitted values, it also iterates through each property in the view model and validates said property using the attributes associated to that property. In certain cases, attributes are implicitly evaluated (in our particular case, ReleaseDate has an implicit [Required] attribute because its type is DateTime and therefore cannot be blank).

If any errors are found, they are added to the Errors property of each ModelStateEntry. There is also a property ErrorCount on the ModelState that shows all errors found during the validation. If errors exist for a given POSTed value, the ValidationState of that property becomes Invalid.

In this case, because at least one of the ModelStateEntry instances has an error, the IsValid property of ModelState is now false.

What all of this means is merely this: we are using ASP.NET 5 MVC the way it was intended to be used. The ModelState stores submitted values, calculates the errors associated with each, and allows our controllers to check for said errors as well as the IsValid flag. In many scenarios, this is all we need, and all of it happens behind the scenes!

Custom Validation

There are times when we need more complex validation than ASP.NET 5 provides natively.

Let’s pretend that we now need a new field, Description, for each movie. Let’s also pretend that in addition to not allowing Description to be blank, it also cannot be exactly the same as the Title.

First, we can add the Description field to the view model:

public class AddMovieVM
{
    [Required(ErrorMessage = "The Title cannot be blank.")]
    [DisplayName("Title: ")]
    public string Title { get; set; }

    [Required(ErrorMessage = "The Description cannot be blank.")]
    [DisplayName("Description: ")]
    public string Description { get; set; }

    [DisplayName("Release Date: ")]
    public DateTime ReleaseDate { get; set; }

    [Required(ErrorMessage = "The Runtime Minutes cannot be blank.")]
    [Range(1, int.MaxValue, 
           ErrorMessage = "The Runtime Minutes must be greater than 0.")]
    [DisplayName("Runtime Minutes: ")]
    public int RuntimeMinutes { get; set; }
}

We can also add it to the view:

@model ModelStateCoreDemo.ViewModels.AddMovieVM

<h2>Add Movie</h2>

<form asp-action="AddPost" asp-controller="Movie" method="post">
    <div>
        <div>
            <label asp-for="Title"></label>
            <input type="text" asp-for="Title" />
            <span asp-validation-for="Title"></span>
        </div>
        <div>
            <label asp-for="Description"></label>
            <input type="text" asp-for="Description" />
            <span asp-validation-for="Description"></span>
        </div>
        <div>
            <label asp-for="ReleaseDate"></label>
            <input type="date" asp-for="ReleaseDate" />
            <span asp-validation-for="ReleaseDate"></span>
        </div>
        <div>
            <label asp-for="RuntimeMinutes"></label>
            <input type="number" asp-for="RuntimeMinutes" />
            <span asp-validation-for="RuntimeMinutes"></span>
        </div>
        <div>
            <input type="submit" value="Save" />
        </div>
    </div>
</form> 

When the form is POSTed, we can do custom validation in our controllers. To check that the Description does not exactly match the Title, we can modify the POST action on our MovieController class like so:

public class MovieController : Controller
{
    //... Other methods

    [HttpPost("movies/add/post")]
    public IActionResult AddPost(AddMovieVM model)
    {
        if(model.Title == model.Description)
        {
            ModelState.AddModelError("description", 
                "The Description cannot exactly match the Title.");
        }

        if(!ModelState.IsValid)
        {
            return View("Add", model);
        }

        return RedirectToAction("Index");
    }
}

Which will show the error next to the input for Description:

Summary

In ASP.NET 5 MVC, the ModelState property of a controller represents the submitted values, and validation errors in those values if such errors exist, during a POST action.

During the POST, the values submitted can be validated, and the validation process uses attributes defined by .NET like [Required] and [Range]. We can do simple custom validation server-side by modifying our controllers.

On views, the asp-validation-for property on a <span> element will show an error message for a specific property of the view model.

Debugging a missing controller

A while ago I was converting an ASP.NET application to ASP.NET Core. The solution had many class library projects, where each project represented a module or vertical slice of the application. These modules contained everything for that feature: the database code, the domain, and the Web API controllers. There was then a “top level” application that referenced all these modules and served the requests.

As the whole solution was based on Katana/Owin and used Web API controllers exclusively, it wasn’t too hard to convert it to ASP.NET Core. But, of course, there were bugs in the conversion process. One thing that had me stumped for a while was why the controllers from some of the modules didn’t seem to be working. All of the requests to certain modules were returning 404s.

There were a few possibilities in my mind for what was going wrong:

1. There was a routing issue, so requests meant for the controllers were not reaching them
2. There was a problem with the controllers themselves, meaning they were generating 404s
3. The ASP.NET Core app wasn’t aware of the controllers in the module at all.

My gut feeling was the problem was either 1 or 3, but I needed a way to check. The solution I present in this post let me rule out point 3, by listing all the ApplicationParts and controllers the app was aware of.

What are application parts?

Application Parts allow you to share the same resources (controllers, Razor Pages etc) between multiple apps. If you’re familiar with Razor Class Libraries, then think of application parts as being the abstraction behind it.

One application part implementation is an AssemblyPart which is an application part associated with an assembly. This is the situation I had in the app I described previously – each of the module projects was compiled into a separate Assembly, and then added to the application as application parts.

You can add application parts in ConfigureServices when you configure MVC. The current assembly is added automatically, but you can add additional application parts too. The example below adds the assembly that contains TestController (which resides in a different project) as an application part.

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddControllers()
        .AddApplicationPart(typeof(TestController).Assembly);
}

Note that in ASP.NET Core 3.x, when you compile an assembly that references ASP.NET Core, an assembly attribute is added to the output, [ApplicationPart]. ASP.NET Core 3.x apps look for this attribute on referenced assemblies and registers them as application parts automatically, so the code above isn’t necessary.

We’ve covered how you register application parts, but how do we debug when things go wrong?

Providing features with the ApplicationPartManager

When you add an application part (or when ASP.NET Core adds it automatically), it’s added to the ApplicationPartManager. This class is responsible for keeping track of all the application parts in the app, and for populating various features based on the registered parts, in conjunction with registered feature providers.

There are a variety of features used in MVC, such as the ControllerFeature and ViewsFeature for example. The ControllerFeature (shown below) contains a list of all the controllers available to an application, across all of the registered application parts.

public class ControllerFeature
{
    public IList<TypeInfo> Controllers { get; } = new List<TypeInfo>();
}

The list of controllers is obtained by using the ControllerFeatureProvider. This class implements the IApplicationFeatureProvider<T> interface, which, when given a list of application parts, populates an instance of ControllerFeature with all the controllers it finds.

public class ControllerFeatureProvider : IApplicationFeatureProvider<ControllerFeature>
{
    public void PopulateFeature(IEnumerable<ApplicationPart> parts, ControllerFeature feature)
    {
        // Loop through all the application parts
        foreach (var part in parts.OfType<IApplicationPartTypeProvider>())
        {
            // Loop through all the types in the application part
            foreach (var type in part.Types)
            {
                // If the type is a controller (and isn't already added) add it to the list
                if (IsController(type) && !feature.Controllers.Contains(type))
                {
                    feature.Controllers.Add(type);
                }
            }
        }
    }

    protected virtual bool IsController(TypeInfo typeInfo) => { /* Elided for brevity*/ }
}

The ApplicationPartManager exposes a PopulateFeature method which calls all the appropriate feature providers for a given feature:

public class ApplicationPartManager
{
    // The list of application parts
    public IList<ApplicationPart> ApplicationParts { get; } = new List<ApplicationPart>();

    // The list of feature providers for the various possible features
    public IList<IApplicationFeatureProvider> FeatureProviders { get; } =
            new List<IApplicationFeatureProvider>();


    // Populate the feature of type TFeature
    public void PopulateFeature<TFeature>(TFeature feature)
    {
        foreach (var provider in FeatureProviders.OfType<IApplicationFeatureProvider<TFeature>>())
        {
            provider.PopulateFeature(ApplicationParts, feature);
        }
    }

That covers all the background for ApplicationPartManager and features.

Listing all the Application parts and controllers added to an application

To quickly work out whether my 404 problem was due to routing or missing controllers, I needed to interrogate the ApplicationPartManager. If the application parts and controllers for the problematic modules were missing, then that was the problem; if they were present, then it was probably some sort of routing issue!

To debug the issue I wrote a quick IHostedService that logs the application parts added to an application, along with all of the controllers discovered.

I used an IHostedService because it runs after application part discovery, and only executes once on startup.

The example below takes an ILogger and the ApplicationPartManager as dependencies. It then lists the names of the application parts, populates an instance of the ControllerFeature, and lists all the controllers known to the app. These are written to a log message which can be safely inspected

A similar example in the documentation exposes this information via a Controller, which seems like a bit of a bad idea to me!

public class ApplicationPartsLogger : IHostedService
{
    private readonly ILogger<ApplicationPartsLogger> _logger;
    private readonly ApplicationPartManager _partManager;

    public ApplicationPartsLogger(ILogger<ApplicationPartsLogger> logger, ApplicationPartManager partManager)
    {
        _logger = logger;
        _partManager = partManager;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        // Get the names of all the application parts. This is the short assembly name for AssemblyParts
        var applicationParts = _partManager.ApplicationParts.Select(x => x.Name);

        // Create a controller feature, and populate it from the application parts
        var controllerFeature = new ControllerFeature();
        _partManager.PopulateFeature(controllerFeature);

        // Get the names of all of the controllers
        var controllers = controllerFeature.Controllers.Select(x => x.Name);

        // Log the application parts and controllers
        _logger.LogInformation("Found the following application parts: '{ApplicationParts}' with the following controllers: '{Controllers}'",
            string.Join(", ", applicationParts), string.Join(", ", controllers));

        return Task.CompletedTask;
    }

    // Required by the interface
    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}

All that remains is to register the hosted service in Startup.ConfigureServices:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddHostedService<ApplicationPartsLogger>();
}

Below is example log message, in which an API project (ApplicationPartsDebugging.Api) references a class library (ApplicationPartsDebugging.Controllers) which contains a controller, TestController.

info: ApplicationPartsDebugging.Api.ApplicationPartsLogger[0]
      Found the following application parts: 'ApplicationPartsDebugging.Api, ApplicationPartsDebugging.Controllers' 
      with the following controllers: 'WeatherForecastController, TestController'

Both the API app and the class library are referenced as application parts, and controllers from both application parts are available.

And yes, this was exactly the problem I had during my conversion, I’d failed to register one of the modules as an application part, shown by it’s absence from my log message!

Summary

In this post I described a problem I faced when converting an application to ASP.NET Core – the controllers from a referenced project could not be found. ASP.NET Core looks for controllers, views, and other features in application parts that it knows about. You can add additional application parts to an ASP.NET Core manually, though ASP.NET Core 3.x will generally handle this for you automatically. To debug my problem I created an ApplicationPartsLogger that lists all the registered application parts for an app. This allows you to easily spot when an expected assembly is missing.

Create a Named HTTPClient

Create an ASP.NET Core Project

Let’s look at step by step to understand and create named HTTPClient approach where we shall be creating HTTPClient request object using HTTPClientFactory.

Interface IHTTPClientFactory  can be injected in Controller or any other class as needed using Constructor injection as below,

Add using namespace ‘System.Net.Http’ in the code to access HTTPClient and IHTTPClientFactory 

Please update the ConfigureServices method in Startup.cs as below,

Here in below example, we are creating two types of Named client,

• AccountClient – This client is configured for AccountSpecific request and accept ‘application/json‘ as Content-type
• PayBillClient – This client is configured for Payment and Bill request and accept ‘application/xml‘ as Content-type. It also configured with security using the BasicAuthentication scheme.

public void ConfigureServices(IServiceCollection services)
       {
           services.AddControllers();
           services.AddHttpClient("AccountClient", c =>
           {
               c.BaseAddress = new Uri(Configuration.GetValue<string>("AccountURL"));
               // Account API ContentType
               c.DefaultRequestHeaders.Add("Accept", "application/json");
           });
           services.AddHttpClient("PayBillClient", c =>
           {
               c.BaseAddress = new Uri(Configuration.GetValue<string>("PayBillURL"));
               // Account API ContentType
               c.DefaultRequestHeaders.Add("Accept", "application/xml");
           });
       }

Below is the client-side code base for named HTTPClient.

Here we specify the name of the HTTPClient request using an overloaded method CreateClient(“client name”).

[HttpGet]
        public async Task<IActionResult> OnGet()
        {
            var uri = new Uri("https://localhost:44364/account");
            var client = _clientFactory.CreateClient("AccountClient");
            var response = await client.GetAsync(uri);
            if (response.IsSuccessStatusCode)
            {
                return Ok(response.Content.ReadAsStreamAsync().Result);
            }
            else
            {
                return StatusCode(500, "Somthing Went Wrong! Error Occured");
            }
        }

Similarly, other named HTTPClient for “PayBillClient” can be created as below,

var client = _clientFactory.CreateClient("PayBillClient");

As we understood above HTTPClientFactory lets you DI inject the HTTPClient objects using an explicit Dependency Injection principle(DI).

This technique can be used configure multiple HTTPClients request with custom configuration of Policy, Security and delegates as required.

This technique lets you control the lifetime management of HTTPClient instances through the API pipeline itself.

With this technique, we are able to centralize multiple clients with specific configurations like using network credentials, specific headers or security tokens as needed.

That’s All, Happy coding !!. Please sound off your comments below.

Summary

In this article, we looked at how to use HTTPClientFactory for creating Named HTTPClient request object to invoke HTTP services in ASP.NET Core. This technique also lets you control custom clients based on the required policy and delegates.

1st Method

In web.config file, set the sessionstate mode to inproc and authentication mode to Forms

<system.web>
<compilation debug="true"/>
<authentication mode="Forms"/>
<sessionState mode="InProc" cookieless="false" timeout="1">
</sessionState>
</system.web> 

I’ve created three pages in this example , one is login page , when session expires , I redirect to this page , one is navigation page where I’ll check if session is valid or not , if it is valid than only user will see this page other wise he gets redirected to login page.

Add Global.asax class file in root of your application or website.
This method works only if Global.asax is present in application.

Write below mentioned code in Page_Init event of the page where we want to check for session timeout.

we can also put this code in in a class and inherit all pages of application from this class acting as base class for all pages to check for session timeout.

C# CODE

protected void Page_Init(object sender, EventArgs e)
    {
        if (Context.Session != null)
        {
            if (Session.IsNewSession)
            {
                HttpCookie newSessionIdCookie = Request.Cookies["ASP.NET_SessionId"];
                if (newSessionIdCookie != null)
                {
                    string newSessionIdCookieValue = newSessionIdCookie.Value;
                    if (newSessionIdCookieValue != string.Empty)
                    {
                        // This means Session was timed Out and New Session was started
                        Response.Redirect("Login.aspx");
                    }
                }
            }
        }
    }

VB.NET

Protected Sub Page_Init(sender As Object, e As EventArgs)
 If Context.Session IsNot Nothing Then
  If Session.IsNewSession Then
   Dim newSessionIdCookie As HttpCookie = Request.Cookies("ASP.NET_SessionId")
   If newSessionIdCookie IsNot Nothing Then
    Dim newSessionIdCookieValue As String = newSessionIdCookie.Value
    If newSessionIdCookieValue <> String.Empty Then
     ' This means Session was timed Out and New Session was started
     Response.Redirect("Login.aspx")
    End If
   End If
  End If
 End If
End Sub

2nd Method.

Code for Default.aspx

<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Button ID="btnSessionStart"
runat="server"
OnClick="btnSessionStart_Click"
Text="Start Session" /><br />
<br />
<br />
<asp:Button ID="btnCheck"
runat="server"
OnClick="btnCheck_Click"
Text="Check Session ID" />
<br />
<asp:TextBox ID="txtSession"
runat="server"
Width="266px">
</asp:TextBox><br />
<br />
<asp:Button ID="btnGO"
runat="server"
OnClick="btnGO_Click"
Text="Go to Other Page" />
<br />
<br />
</div>
</form>
</body>
</html>

And the code behind for this page is like

protected void btnSessionStart_Click
(object sender, EventArgs e)
{
Guid Session_id = Guid.NewGuid();
Session["SessionID"]
= Session_id.ToString();

}
protected void btnCheck_Click
(object sender, EventArgs e)
{
if (Session["SessionID"] != null)
txtSession.Text =
Session["SessionID"].ToString();
else
txtSession.Text =
"Session has expired";
}
protected void btnGO_Click
(object sender, EventArgs e)
{
Response.Redirect("Default2.aspx");
}

On the page where we want to check the session has timed out or not, we need to check it in the Page_Init event of the page , if session is not null than user will be able to go to the page other wise he will be redirected to login page.

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Button ID="btnHome"
runat="server" OnClick="btnHome_Click"
Text="Home" /></div>
</form>
</body>
</html>

And the Code behind for this page is

protected void Page_Init(object sender, EventArgs e)
{
CheckSession();
}
protected void btnHome_Click(object sender, EventArgs e)
{
Response.Redirect("Default.aspx");
}

private void CheckSession()
{
if (Session["SessionID"] == null)
{
Response.Redirect("Login.aspx");
}

}

If we need to check this in all the pages of application than we can create a BaseClass and write the above mentioned code of CheckSession and Page_Init part and drive all ur pages from this class by typing BaseClassName in place of System.Web.UI.Page and it will check all pages for session timeout every time page is loaded

For many website owners, it’s their white whale. Getting a perfect score on PageSpeed Insights is the impossible quest that will magically solve all of their page speed woes.

But is a high PageSpeed Insights score the be-all and end-all of fast page load times? Sorry, but no. If your focus is on improving your site’s page load times, finding a better ASP.NET host will often take you further.

In this post, I’m going to run a real test to show you that high-performance hosting will do more for your page load times than endlessly striving to improve your PageSpeed Insights score.

Google PageSpeed Insights. What is it?

If you’re not already familiar, PageSpeed Insights is a Google-offered tool that helps you both analyze and optimize your website’s performance for desktop and mobile visitors. Before I get into what exactly that entails, let’s talk about what PageSpeed Insights is not:

It’s not a tool that gives you a real number for how long your page takes to load. You need other tools for that. Instead, PageSpeed Insights gives you a score from 0-100 based on how well your site is technically optimized, with separate scores for desktop and mobile.

To calculate this score, Google uses two metrics (direct quote):

• time to above-the-fold load: Elapsed time from the moment a user requests a new page and to the moment the above-the-fold content is rendered by the browser.
• time to full page load: Elapsed time from the moment a user requests a new page to the moment the page is fully rendered by the browser.

And while Google’s suggestions are important, they readily admit that the test “only considers the network-independent aspects of page performance”. That means PageSpeed Insights does not, among other aspects, directly consider the speed of your host.

So while PageSpeed Insights gives you great suggestions for speeding up the technical aspects of your page, getting a perfect score on PageSpeed Insights will never be enough to completely overcome a slow host.

In Google’s own words, the “absolute performance of the page will still be dependent upon a user’s network connection.”

* It should be noted that Google is also talking about a visitor’s personal Internet speed.

Is it Really Important to have High PageSpeed Score?

Plenty of data says that users care about how quickly your page loads in absolute terms. Akamai found that, at least for eCommerce sites, 30% of users want sites to load in under 1 second. And on mobile, 74% of users will abandon a site that takes longer than 5 seconds to load.

But as we learned in the previous section, PageSpeed Insights does not calculate the absolute page load time of your site.

So, is it Important to have High PageSpeed Insights?

Yes and no. A higher PageSpeed Insights score will likely improve the speed of your website. It will get you a quicker loading site.

But here’s the thing:

Your website will only ever be as fast as the hardware that’s powering it. A high-quality web host and good caching will almost always take you further than a 25-point improvement in your PageSpeed Insights score.

I have tested my ASP.NET site in ASPHostPortal hosting, with simple ASP.NET site.

Using those settings, I’ll run each site through PageSpeed Insights and use Pingdom Tools (testing from San Jose) to calculate the absolute page load time for each site. I’ll use PageSeed Insights’ Desktop score for the purposes of this test.

Testing Result – PageSpeed Insights vs Faster ASP.NET Hosting

After running the tests and crunching the numbers, here are the results I came up with.

ASPHostPortal Test 1 – Unoptimized PageSpeed Insights score:

My unoptimized ASPHostPortal test site had a mediocre PageSpeed Insights score of 66/100:

Pingdom’s calculated page load time was better than I expected, clocking in at 2.00 seconds. That’s actually not horrible. But remember that I’m testing on a dummy site without much content:

ASPHostPortal Test 2 – Optimized PageSpeed Insights score:

After making the tweaks I mentioned above, I got the PageSpeed Insights score for my ASPHostPortal test site up to 90/100. A major improvement from 66 and worthy of the coveted “green” seal of approval:

So what was the effect on actual page load times? A marked improvement to 947 ms.

Summary

I don’t want you to come away from this post thinking that you should ignore Google PageSpeed Insights. The people at Google are way smarter than I am. They know what they’re doing.

All I’m saying is this…

Focus most on what’s actually important – absolute page load times. PageSpeed Insights is not the end of your optimization journey. Nor should it always be your primary focus.

When it comes to absolute page load times (the important thing!), switching to a faster ASP.NET host and implementing good caching will have a much larger effect than trying to go from 66 to a 90 PageSpeed Insights score on sub-par hosting.

To test if the injector is working correctly, create a service that implements an interface

    public interface ITestService
    {
        string GetData();
    }

    public class TestService : ITestService
    {
        public string GetData()
        {
            return "some magic string";
        }
    }

Download the package from Nuget

Using the package manager console Install-Package Ninject -Version 3.3.4

Using dotnet cli dotnet add package Ninject --version 3.3.4

Add these members to Startup.cs class as shown below

    private readonly AsyncLocal<Scope> scopeProvider = new AsyncLocal<Scope>();
    private IKernel Kernel { get; set; }

    private object Resolve(Type type) => Kernel.Get(type);
    private object RequestScope(IContext context) => scopeProvider.Value;  

    private sealed class Scope : DisposableObject { }

Add the following binding in the end of ConfigureServices (Startup.cs)

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

Create class RequestScopingStartupFilter implementing the IStartupFilter interface

    public sealed class RequestScopingStartupFilter : IStartupFilter
    {
        private readonly Func<IDisposable> requestScopeProvider;

        public RequestScopingStartupFilter(Func<IDisposable> requestScopeProvider)
        {
            if (requestScopeProvider == null)
            {
                throw new ArgumentNullException(nameof(requestScopeProvider));
            }

            this.requestScopeProvider = requestScopeProvider;
        }

        public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> nextFilter)
        {
            return builder =>
            {
                ConfigureRequestScoping(builder);

                nextFilter(builder);
            };
        }

        private void ConfigureRequestScoping(IApplicationBuilder builder)
        {
            builder.Use(async (context, next) =>
            {
                using (var scope = this.requestScopeProvider())
                {
                    await next();
                }
            });
        }
    }

Create a static class AspNetCoreExtensions with the following extension method

    using System;
    using Microsoft.AspNetCore.Hosting;
    using Microsoft.Extensions.DependencyInjection;

    public static class AspNetCoreExtensions
    {
        public static void AddRequestScopingMiddleware(this IServiceCollection services, 
            Func<IDisposable> requestScopeProvider)
        {
            if (services == null)
            {
                throw new ArgumentNullException(nameof(services));
            }

            if (requestScopeProvider == null)
            {
                throw new ArgumentNullException(nameof(requestScopeProvider));
            }

            services
                .AddSingleton<IStartupFilter>(new
                    RequestScopingStartupFilter(requestScopeProvider));
        }
    }

Configure to use the middleware in ConfigureServices(in the end of the method)

services.AddRequestScopingMiddleware(() => scopeProvider.Value = new Scope());

Create a file Activators.cs with the following

   public sealed class DelegatingControllerActivator : IControllerActivator
        {
            private readonly Func<ControllerContext, object> controllerCreator;
            private readonly Action<ControllerContext, object> controllerReleaser;

            public DelegatingControllerActivator(Func<ControllerContext, object> controllerCreator,
                Action<ControllerContext, object> controllerReleaser = null)
            {
                this.controllerCreator = controllerCreator ?? 
                    throw new ArgumentNullException(nameof(controllerCreator));
                this.controllerReleaser = controllerReleaser ?? ((_, __) => { });
            }

            public object Create(ControllerContext context) => this.controllerCreator(context);
            public void Release(ControllerContext context, object controller) =>             
                this.controllerReleaser(context, controller);
        }

Add the following extension method to AspNetCoreExtensions.cs

        public static void AddCustomControllerActivation(this IServiceCollection services,
            Func<Type, object> activator)
        {
            if (services == null) throw new ArgumentNullException(nameof(services));
            if (activator == null) throw new ArgumentNullException(nameof(activator));

            services.AddSingleton<IControllerActivator>(new DelegatingControllerActivator(
                context => activator(context.ActionDescriptor.ControllerTypeInfo.AsType())));
        }

Append the following to the end of ConfigureServices

services.AddCustomControllerActivation(Resolve);

Add another class to Activators.cs

        public sealed class DelegatingViewComponentActivator : IViewComponentActivator
        {
            private readonly Func<Type, object> viewComponentCreator;
            private readonly Action<object> viewComponentReleaser;

            public DelegatingViewComponentActivator(Func<Type, object> viewComponentCreator,
                Action<object> viewComponentReleaser = null)
            {
                this.viewComponentCreator = viewComponentCreator ?? 
                    throw new ArgumentNullException(nameof(viewComponentCreator));
                this.viewComponentReleaser = viewComponentReleaser ?? (_ => { });
            }

            public object Create(ViewComponentContext context) =>
                this.viewComponentCreator(context.ViewComponentDescriptor.TypeInfo.AsType());

            public void Release(ViewComponentContext context, object viewComponent) =>
                this.viewComponentReleaser(viewComponent);
        }

And another extension method in AspNetCoreExtensions.cs

       public static void AddCustomViewComponentActivation(this IServiceCollection services, 
            Func<Type, object> activator)
        {
            if (services == null) throw new ArgumentNullException(nameof(services));
            if (activator == null) throw new ArgumentNullException(nameof(activator));

            services.AddSingleton<IViewComponentActivator>(
new DelegatingViewComponentActivator(activator));
        }

then call it form ConfigureServices (should be the last invoked)

This is what ConfigureServices should look like now

        public void ConfigureServices(IServiceCollection services)
        {
            // Other configurations

            services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

            services.AddRequestScopingMiddleware(() => scopeProvider.Value = new Scope());
            services.AddCustomControllerActivation(Resolve);
            services.AddCustomViewComponentActivation(Resolve);

        }

Create an ApplicationBuilderExtensions.cs with a static class in it

    using System;
    using System.Globalization;
    using System.Linq;
    using Microsoft.AspNetCore.Builder;
    using Microsoft.AspNetCore.Http;
    using Microsoft.AspNetCore.Mvc.ApplicationParts;
    using Microsoft.AspNetCore.Mvc.Controllers;
    using Microsoft.Extensions.DependencyInjection;
    using Ninject;

    public static class ApplicationBuilderExtensions
    {
        public static void BindToMethod<T>(this IKernel config, Func<T> method)
 => config.Bind<T>().ToMethod(c => method());

        public static Type[] GetControllerTypes(this IApplicationBuilder builder)
        {
            var manager = builder.ApplicationServices.GetRequiredService<ApplicationPartManager>();

            var feature = new ControllerFeature();
            manager.PopulateFeature(feature);

            return feature.Controllers.Select(t => t.AsType()).ToArray();
        }

        public static T GetRequestService<T>(this IApplicationBuilder builder) where T : class
        {
            if (builder == null) throw new ArgumentNullException(nameof(builder));

            return GetRequestServiceProvider(builder).GetService<T>();
        }

        private static IServiceProvider GetRequestServiceProvider(IApplicationBuilder builder)
        {
            var accessor = builder.ApplicationServices.GetService<IHttpContextAccessor>();

            if (accessor == null)
            {
                throw new InvalidOperationException(      
          typeof(IHttpContextAccessor).FullName);
            }

            var context = accessor.HttpContext;

            if (context == null)
            {
                throw new InvalidOperationException("No HttpContext.");
            }

            return context.RequestServices;
        }
    }

Add the following method in Startup class

        private IKernel RegisterApplicationComponents(IApplicationBuilder app)
        {
            // IKernelConfiguration config = new KernelConfiguration();
            var kernel = new StandardKernel();

            // Register application services
            foreach (var ctrlType in app.GetControllerTypes())
            {
                kernel.Bind(ctrlType).ToSelf().InScope(RequestScope);
            }

            // This is where our bindings are configurated
             kernel.Bind<ITestService>().To<TestService>().InScope(RequestScope);            

            // Cross-wire required framework services
            kernel.BindToMethod(app.GetRequestService<IViewBufferScope>);

            return kernel;
        }

and call it from Configure (in the beginning)

this.Kernel = this.RegisterApplicationComponents(app);

Create a TestController to see if our DI works

    [Route("api/[controller]")]
    public class ValuesController : Controller
    {
        private readonly ITestService testService;

        public ValuesController(ITestService testService)
        {
            this.testService = testService;
            this.factory = factory;
        }

        [HttpGet]
        public IActionResult Get()
        {
            var result = this.testService.GetData();

            return this.Ok(result);
        }
    }

Place a breakpoint in the constructor of our TestService and in the Getaction to see the magic.

We will use the dot-net CLI to create a new project and configure it using the reload technique in combination with IOptionsSnapshot.

Make sure you are using at least ASP.NET Core 1.1. Get started by creating a new folder that you want to work in, opening a console there and typingdotnet new mvc and dotnet restore to get the project in a starting position. Then open up a console and type code. to start Visual Studio Code on the current level.

You should now see all the files and folders of your project. We can now go ahead and create a typed class which represents the configuration we want to work with. In this case, this is just a file with a name property.

Config 
  └── myConfig.json 
  Controllers └── ... 
  Views └── ... 
  wwwroot └── ... ... 
  Program.cs 
  Startup.cs

myConfig.json

{
    "Person": {
        "Firstname": "John Doe"
    }
}

This leads us to the class

public class Person  
{
    public string Firstname { get; set; }
}

Config  
  └── myConfig.json  
  Controllers └── ...  
  Views └── ...  
  wwwroot └── ... ...  
  Program.cs  
  Startup.cs

which represents our configuration in our application.

We have to modify our constructor of the Startup.cs file a bit to load this new file:

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

This then becomes:

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddJsonFile($"config/myConfig.json", optional: false, reloadOnChange: true)
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

Pay attention to the realoadOnChange: true because that is what we are reaching out for.

So now that we loaded the file we need to add it to our configuration which is used in our app. Let’s do this by adding the statement in the ConfigureServices-Method:

public void ConfigureServices(IServiceCollection services)
{
    // ...
    services.Configure<Person>(Configuration.GetSection("Person"));
}

Here we are mapping our values in JSON to a typed class called “Person.”

Now, this configuration is available through dependency injection and we can use it in our controllers!

public class HomeController : Controller  
{
    private readonly Person _person;
    public HomeController(IOptionsSnapshot<Person> person)
    {
        _person = person.Value;
    }
}

Pay attention to the “IOptionsSnapshot” we injected here which is different from the previous ASP.NET Core versions. Be sure to have the “Microsoft.Extensions.Options”: “1.1.0” package installed and that you are using ASP.NET Core 1.1. We can now inject the IOptionsSnapshot<T> in our controller and use its value. For testing, we save the Firstname in the ViewData displaying it afterward.

namespace WebApplication6.Controllers
{
    public class HomeController : Controller
    {
        private readonly Person _person;
        public HomeController(IOptionsSnapshot<Person> person)
        {
            _person = person.Value;
        }
        public IActionResult Index()
        {
            ViewData["FirstName"] = _person.Firstname;
            return View();
        }
    }
}

Index.cshtml

<h3>@(ViewData["FirstName"])</h3>

If you now start the web application via dotnet run and you change the configuration without restarting the application, hit F5 to refresh the browser and you will see the new values.