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.

How to Send HTML Email in ASP.NET Core

This code sends a simple HTML email using the Ethereal free SMTP testing service, you can create a free test account in one click at https://ethereal.email/ and copy the username and password from below the title SMTP configuration. See instructions below for using different SMTP providers such as Gmail and Hotmail.

// create email message
var email = new MimeMessage();
email.From.Add(MailboxAddress.Parse("from_address@example.com"));
email.To.Add(MailboxAddress.Parse("to_address@example.com"));
email.Subject = "Test Email Subject";
email.Body = new TextPart(TextFormat.Html) { Text = "<h1>Example HTML Message Body</h1>" };

// send email
using var smtp = new SmtpClient();
smtp.Connect("smtp.ethereal.email", 587, SecureSocketOptions.StartTls);
smtp.Authenticate("[USERNAME]", "[PASSWORD]");
smtp.Send(email);
smtp.Disconnect(true);

How to Send Plain Text Email in ASP.NET Core

This code sends the same email as above with a plain text body.

// create email message
var email = new MimeMessage();
email.From.Add(MailboxAddress.Parse("from_address@example.com"));
email.To.Add(MailboxAddress.Parse("to_address@example.com"));
email.Subject = "Test Email Subject";
email.Body = new TextPart(TextFormat.Plain) { Text = "Example Plain Text Message Body" };

// send email
using var smtp = new SmtpClient();
smtp.Connect("smtp.ethereal.email", 587, SecureSocketOptions.StartTls);
smtp.Authenticate("[USERNAME]", "[PASSWORD]");
smtp.Send(email);
smtp.Disconnect(true);

Change Your SMTP Provider

To change the above code to use a different email provider simply update the host parameter (the first parameter) passed to the smtp.Connect() method, for example:

// gmail
smtp.Connect("smtp.gmail.com", 587, SecureSocketOptions.StartTls);

// hotmail
smtp.Connect("smtp.live.com", 587, SecureSocketOptions.StartTls);

// office 365
smtp.Connect("smtp.office365.com", 587, SecureSocketOptions.StartTls);

Wrapping it up in an Email Service

To encapsulate the email sending functionality and make it easy to send email from anywhere in your ASP.NET Core application you can create an EmailService class and IEmailService interface like below.

using MailKit.Net.Smtp;
using MailKit.Security;
using Microsoft.Extensions.Options;
using MimeKit;
using MimeKit.Text;
using WebApi.Helpers;

namespace WebApi.Services
{
    public interface IEmailService
    {
        void Send(string from, string to, string subject, string html);
    }

    public class EmailService : IEmailService
    {
        private readonly AppSettings _appSettings;

        public EmailService(IOptions<AppSettings> appSettings)
        {
            _appSettings = appSettings.Value;
        }

        public void Send(string from, string to, string subject, string html)
        {
            // create message
            var email = new MimeMessage();
            email.From.Add(MailboxAddress.Parse(from));
            email.To.Add(MailboxAddress.Parse(to));
            email.Subject = subject;
            email.Body = new TextPart(TextFormat.Html) { Text = html };

            // send email
            using var smtp = new SmtpClient();
            smtp.Connect(_appSettings.SmtpHost, _appSettings.SmtpPort, SecureSocketOptions.StartTls);
            smtp.Authenticate(_appSettings.SmtpUser, _appSettings.SmtpPass);
            smtp.Send(email);
            smtp.Disconnect(true);
        }
    }
}

Conclusion

I hope above tutorial can help you if you encounter issue when send email via your Asp.net Core application. See you on next tips!

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

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.

ASP.NET Core is a set of libraries you can install into a project using the NuGet package manager. One of the packages you might install for HTTP message processing is a package named Microsoft.AspNetCore.Server.Kestrel. The word server is in the name because this new version of ASP.NET includes its own web servers, and the featured server has the name Kestrel.

In the animal kingdom, a Kestrel is a bird of prey in the falcon family, but in the world of ASP.NET, Kestrel is a cross-platform web server. Kestrel builds on top of libuv, a cross-platform library for asynchronous I/O. libuv gives Kestrel a consistent streaming API to use across Windows and Linux. You also have the option of plugging in a server based on the Windows HTTP Server API (Web Listener), or writing your own IServer implementation. Without good reason, you’ll want to use Kestrel by default.

An Overview of How It Works

You can configure the server for your application in the entry point of the application. There is no Application_Start event in this new version of ASP.NET, nor is there any default XML configuration files. Instead, the start of the application is a static Main method, and configuration lives in the code.

public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
            .UseKestrel()
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseIISIntegration()
            .UseStartup<Startup>()
            .Build(); 

        host.Run();
    }
}

If you are looking at the above Program class with a static Main method and thinking the code looks like what you would see in a .NET console mode application, then you are thinking correctly. Compiling an ASP.NET project still produces a .dll file, but with .NET Core we launch the web server from the command line with the dotnet command line interface. The dotnet host will ultimately call into the Main method. In this way of working, .NET Core resembles environments like Java, Ruby, and Python.

If you are working on ASP.NET Core from Visual Studio, then you might never see the command line. Visual Studio continues to do a job it has always done, which is to hide some of the lower level details. With Visual Studio, you can set the application to run with Kestrel as a direct host, or to run the application in IIS Express (the default setting). In both cases, the dotnet host and Kestrel server are in play, even when using IIS Express. This brings us to the topic of running applications in production.

ASP.NET Core Applications in Production

One you realize that ASP.NET includes a cross-platform host and web server, you might think you have all the pieces you need to push to production. There is some truth to this line of thought. Once you’ve invoked the Run method on the WebHost object in the above code, you have a running web server that will listen to HTTP requests and can work on everything from a 32 core Linux server to a Raspberry Pi. However, Microsoft strongly suggests using a hardened reverse proxy in front of your Kestrel server in production. The proxy could be IIS on Windows, or Apache or NGINX.

Why the reverse proxy? In short because technologies like IIS and Apache have been around for over 20 years and have seen all the evils the Internet can deliver to a network socket. Kestrel, on the other hand, is still a newborn babe. Also, reliable servers require additional infrastructure like careful process management to restart failed applications. Outside of ASP.NET, in the world of Java, Python, Ruby, and NodeJS web apps, you’ll see tools like Phusion Passenger and PM2 work in combination with the reverse proxy. These types of tools provide the watchdog monitoring, logging, balancing, and overall process management needed for a robust server. With ASP.NET Core on Windows you can use IIS to achieve the same goals. HTTP requests will still arrive at IIS first, and IIS can forward requests to the Kestrel application. You can have multiple applications deployed behind a single instance of IIS, and IIS will manage the application and provide logging, request filtering, URL rewrites, and many other useful features. In a way, this isn’t much different than what we’ve done in the past with ASP.NET, but once you dig behind the architectural diagrams, you’ll see the details are very different.

What’s Different?

Deploying ASP.NET Core applications to IIS requires a web.config file. ASP.NET Core knows nothing about web.config files. The web.config file only exists to configure IIS in a reverse proxy role. A typical web.config file will look like the following.

<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\TheWebApp.dll" stdoutLogEnabled="false"
                   stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

The web.config file instructs IIS to send requests for all paths and verbs to a new HTTP handler named aspNetCore. This ASP.NET Core Module for IIS is a piece of software you’ll need to install on an IIS server to run ASP.NET Core applications. The ASP.NET Core Module is available with the .NET Core SDK install, or with a special Windows Server Hosting .NET Core installer.

The second bit of the web.config file configures the ASP.NET Core module with instructions on how to start your application, which is to use the same dotnet command we saw earlier. Now, instead of our ASP.NET application running inside of a w3wp.exe IIS worker process, the application will execute inside of a dotnet.exe process.

With a better idea of how ASP.NET Core runs in production, let’s talk about benefits and risks.

Benefits

One benefit to Kestrel is the ability to execute across different platforms. You can author an ASP.NET application on Windows using Visual Studio and IIS Express, but deploy the application on Linux with Apache in front. In all scenarios, the server is always Kestrel and your application code doesn’t need to change.

Another benefit to Kestrel is the incredible work Microsoft has put into making a blazing fast web server with managed code. Inside the readme file for the ASP.NET Benchmarks repository, you’ll currently find benchmarks showing ASP.NET Core serving five times the number of requests per second as ASP.NET 4.6 on the same hardware. 313,001 requests per second compared to 57, 843.

Of course, benchmark code and benchmark results don’t always reflect how a specific business application will behave. It’s like seeing an F1 racing car manufactured by Toyota on the television and then thinking you’ll find a car that goes 220 mph at the local Toyota dealer. What you will find at the dealer are cars that indirectly benefit from the millions of dollars that Toyota puts into researching new technologies for their F1 cars. The benefits trickle down.

I decided to try some comparative benchmarks of my own. I created three applications with ASP.NET WebForms, ASP.NET MVC 5, and ASP.NET MVC Core. Each application delivers 3kb of HTML to the client using the typical patterns you would find in business applications. For example, using a master page in WebForms and using a Layout page in MVC. For ASP.NET MVC Core, I ran tests against a naked Kestrel server as well as a Kestrel server proxied by IIS.

In my tests, the naked Kestrel server delivered 5 times the throughput of WebForms, and over twice the throughput of MVC 5. Once I moved the Core application behind IIS however, throughput dropped below the level of MVC 5. I know these results might surprise many people who believe that ASP.NET Core is inherently faster and lighter than its predecessors. However, ASP.NET Core’s predecessors were deeply integrated into IIS and could execute inside the same worker process where sockets were open. The current recommended setup adds an additional hop.

Another surprise – switching the ASP.NET Core application to run on the full .NET framework instead of .NET Core resulted in very little change in the throughput numbers. As developers, we want to believe .NET Core is also inherently faster and lighter than the full .NET framework, but for runtime performance in this specific application, the difference appears to be negligible.

I do think we can reasonably expect the performance of ASP.NET Core with IIS to improve in the future, so we’ll leave performance as a benefit.

Risks

The biggest risk I’ve seen in the new hosting model is the confusion that results in using IIS with ASP.NET Core. There are ASP.NET related settings in IIS that have no impact on a .NET Core application. These are settings like the pipeline mode (integrated or classic), and the setting to select a version of the .NET framework for a specific AppPool.

Developers and IT operations will need to understand the new deployment strategy and understand which IIS settings are significant and which settings to ignore. Both parties will also need to learn new troubleshooting techniques and diagnose a new set of common errors. 502.5 – “Failed to start process” is a terrifying new common error. One reason for this error is that the web.config file specifies incorrect arguments for the dotnet host.

Summary

Currently, I feel the hosting area is one of the bigger areas of risk in ASP.NET Core. However, I think we will be able to mitigate the risks over time through a combination of experience, education, experimentation, and improvements from Microsoft based on customer feedback. It is important for developers and IT operations to look at how to host an ASP.NET core application early and not treat deployment as a known procedure that can wait till the end of the project.