Blazor

Microsoft created the Blazor framework to facilitate the development of contemporary web applications. The primary benefit lies in the fact that developers can utilize C# to directly create dynamic and interactive web applications. To achieve high-performance application development, Blazor uses WebAssembly, a technology that lets back-end code run in the browser similarly to JavaScript, to execute C# programs on the client side.

The introduction given above ought to be sufficient to pique the curiosity of back-end developers who typically work with C#. After actually learning it, I believe the learning curve is fairly easy to navigate if you have some prior knowledge of the C# language. If developers are unfamiliar with the front-end and would like to try learning the full-end, I strongly suggest that they use the Blazor framework as a foundation.

Blazor WebAssembly vs. Blazor Server

Blazor offers two choices for hosting models. Learning was challenging at first. Allow me to clarify the distinctions between the two.

When a user visits the website, the front end uses SignalR, a C# package that implements the WebSocket two-way communication function, to connect to the back end server. The back end provides the majority of the data.

A few advantages are:

• Compared to WebAssembly mode, the initial loading speed is faster.
• In contrast to WebAssembly’s static website, the API’s functionality is retained in the Server model.

Limitations:

• The website cannot be accessed if the network is unstable or breaks midway because SignalR is used to transmit information (if the connection is only momentary, the browser will automatically reconnect).
• For the website to continue to function, users must be connected. There is a maximum number of connection pools determined by the hardware. This implies that issues could arise if numerous users attempt to connect at once!?

Blazor WebAssembly

Conclusion

A completely new framework with great efficiency and flexibility is called Blazor. It is ideal for developers who have experience with the C# language. They are aware of the difficulties faced by back-end engineers who lack front-end experience. They can quickly create a front-end and back-end application for basic applications after using it for personal use. Blazor is a good place to start if you want to communicate with the front-end or full-end.

Understanding the Error 405

Understanding the general meaning of the “405 Method Not Allowed” error is essential before delving into the details of the ASP.NET Core scenario. The error is an HTTP response status code that says that although the target resource for the specified URI does support the request method, the web server has acknowledged it.

Common Reasons for ASP.NET Core on IIS Error 405

• WebDAV Module: The WebDAV module is usually to blame when hosting ASP.NET Core applications on IIS. Using both PUT and DELETE requests, this module is intended for online authoring. Applications that depend on these techniques may be affected if it is not configured properly.
• Missing or Incorrect Verb Handlers: Verb handlers are used by IIS to handle requests. You’ll see a 405 error if these handlers aren’t set up properly for PUT or DELETE.

Solution

If your application does not require WebDAV, you can resolve many issues by simply disabling the WebDAV module. Add the following code to your web.config file:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="false">
        <remove name="WebDAVModule"/>
    </modules>
    <handlers>
        <remove name="WebDAV" />
    </handlers>
</system.webServer>

Additional Tips

• Enable Detailed Error Messages: Be sure your IIS server is set up to display comprehensive error messages in order to gain a better understanding of the underlying cause. This will give additional background information and might even identify the offending module or handler.
• Logging: Include logging in your application for ASP.NET Core. Comprehensive logs that can provide insights into potential problems can be captured by programs like Serilog or the integrated ILogger.
• Check Route Configurations: Make sure the methods you’re attempting to invoke are supported by your ASP.NET Core routing configurations.

Conclusion

With the correct knowledge of its causes and the appropriate resources at your disposal, the “405 Method Not Allowed” error in an ASP.NET Core application hosted on IIS can be overcome. Never forget that every application is different, so before making any changes to infrastructure or configurations, make sure you test everything thoroughly.

In addition to improving user experience, this can lessen the load placed on the webserver when rendering and serving HTML content over the network. In order to create the most effective SPAs, client-side frameworks like Angular, ReactJs, and Ionic have advanced significantly. Let’s discuss how to integrate an SPA powered by Angular inside of an existing ASP.NET Core application in this article.

Assume that the data source for an Angular application is an ASP.NET Core application. We now have two options for deployment: running two instances of both the client and server applications, with the client application configured with the server endpoint. Most of the real-world application deployments we see today are done in this manner.

A webserver like IIS or Apache must once again host an SPA, which is simply an index.html page with a few js files for runtime and client logic.

An innovative method has been developed that sandwiched an angular SPA inside an ASP.NET Core API because we would also need to require the client application to maintain the server address for communication.

With this method, both applications can be created and deployed on a single instance, and they are both local to one another. When a user calls the appropriate routes, the ASPNETCORE application also serves the client application to them. A few libraries must be added to the ASP.NET Core API, and the csproj file must be modified to allow for angular build activities.

Steps to Implement Code in ASP.NET Core

1. Start by copying the Angular application into the ClientApp subdirectory of the ASPNETCORE project. Together with the controllers and other projects, this is located in the root directory. Just keep in mind that since we’re using an ASPNETCORE API project, we don’t have a wwwroot folder or Views folder.

2. Install the package listed below, which supports SPA building and rendering, in the ASPNETCORE project.

<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="3.1.3" />

3. To support SPA, we would need to add a few middlewares and services to the Startup class. The server application would route to an SPA when making specific requests technically because it is just a collection of static files under the ASPNETCORE project. We would also add support for the server to access these static files in order to make this possible.

The middleware functions UseStaticFiles() and UseSpa() for SPA support accomplish this.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
            
    // In production, the Angular files will be served from this directory
    services.AddSpaStaticFiles(configuration =>
    {
        configuration.RootPath = "ClientApp/dist";
    });
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStaticFiles();
    
    // In Production Environment
    // Serve Spa static files
    if (!env.IsDevelopment())
    {
        app.UseSpaStaticFiles();
    }

    // other ASPNETCORE Routing Code
    // Spa middleware to enable
    // SPA request handling
    app.UseSpa(spa =>
    {
        // The directory from which the 
        // SPA files shall be served for
        // client requests
        spa.Options.SourcePath = "ClientApp";

        // When in Development,
        // Since the SPA app is not build
        // use npm start command to run 
        // the node server for local run
        if (env.IsDevelopment())
        {
            spa.UseAngularCliServer(npmScript: "start");
        }
    });
}

4. We make sure the angular build command configuration in the angular.json file of the client application, which is under the ClientApp directory, so that on angular build, the files are created under the /dist folder relative to the Client app path.

        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "progress": false,
            "extractCss": true,
            "outputPath": "dist", <-- ensure this path
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json",
            "assets": ["src/assets"],
            "styles": [
              "node_modules/bootstrap/dist/css/bootstrap.min.css",
              "src/styles.css"
            ],
            "scripts": []
          }
        }

This is significant because, when running, the ASPNETCORE application searches for the Spa files under the services-specified path /ClientApp/dist folder.Method AddSpaStaticFiles().

5. Finally, using the csproj and the changes listed below, we wire up the ClientApp and ASPNETCORE app together during project build.

<ItemGroup>
    <!-- Don't publish the SPA source files, but do show them in the project files list -->
    <Content Remove="$(SpaRoot)**" />
    <None Remove="$(SpaRoot)**" />
    <None Include="$(SpaRoot)**" Exclude="$(SpaRoot)node_modules**" />
  </ItemGroup>

<!-- Debug run configuration -->
  <!-- Check for Nodejs installation, install in the ClientApp -->
  <Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') ">
    <!-- Ensure Node.js is installed -->
    <Exec Command="node --version" ContinueOnError="true">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
    <Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
  </Target>

<!-- Publish time tasks: run npm build along with project publish -->
  <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
    <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build -- --prod" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build:ssr -- --prod" Condition=" '$(BuildServerSideRenderer)' == 'true' " />

    <!-- Include the newly-built files in the publish output -->
    <ItemGroup>
      <DistFiles Include="$(SpaRoot)dist**; $(SpaRoot)dist-server**" />
      <DistFiles Include="$(SpaRoot)node_modules**" Condition="'$(BuildServerSideRenderer)' == 'true'" />
      <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
        <RelativePath>%(DistFiles.Identity)</RelativePath>
        <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
        <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
      </ResolvedFileToPublish>
    </ItemGroup>
  </Target>

In each of these configurations, we define $(SpaRoot) at the top of the csproj file as the ClientApp rootpath:

<PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
    <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
    <IsPackable>false</IsPackable>

    <!-- the path picked up by all the processing -->
    <SpaRoot>ClientApp</SpaRoot>
    <DefaultItemExcludes>$(DefaultItemExcludes);$(SpaRoot)node_modules**</DefaultItemExcludes>
    <!-- Set this to true if you enable server-side prerendering -->
    <BuildServerSideRenderer>false</BuildServerSideRenderer>
</PropertyGroup>

When everything is finished, we can simply publish our project.

and run to see our changes coming into effect.

Configuring Localization in ASP.NET Core

The RequestLocalizationMiddleware middleware must be configured in order to configure localization in ASP.NET Core, which uses middleware to configure the majority of its cross-cutting features. Based on the data sent by the client, this middleware enables the automatic setting of the culture for HTTP requests.

Create a new ASP.NET Core MVC Web Application called AspNetCoreLocalizationDemo in Visual Studio 2019 by clicking the “New” button. Open the Startup.cs file and call the AddLocalization method to configure the localization middleware. The localization services are added to the services container by the AddLocalization method. The relative path under the application root where the resource files are located is specified by the ResourcePath property.

services.AddLocalization(options =>
{
    options.ResourcesPath = "Resources";
});

Additionally, the AddViewLocalization method, which we will use later in this tutorial, adds support for localized view files.

services.AddControllersWithViews()
    .AddViewLocalization();

Note that the AddDataAnnotationsLocalization method in ASP.NET Core also adds support for localized DataAnnotations.

Next, we must decide which cultures our application will support and which one will serve as the default culture. Let’s configure these three cultures as follows since I want to support the French, German, and English languages in this tutorial:

services.Configure<RequestLocalizationOptions>(options =>
{
    options.DefaultRequestCulture = new RequestCulture("en-US");
 
    var cultures = new CultureInfo[]
    {
        new CultureInfo("en-US"),
        new CultureInfo("de-DE"),
        new CultureInfo("fr-FR")
    };
 
    options.SupportedCultures = cultures;
    options.SupportedUICultures = cultures;
});

Following is the complete code of the ConfigureServices method.

public void ConfigureServices(IServiceCollection services)
{
    services.AddLocalization(options =>
    {
        options.ResourcesPath = "Resources";
    });
 
    services.AddControllersWithViews()
        .AddViewLocalization();
 
    services.Configure<RequestLocalizationOptions>(options =>
    {
        options.DefaultRequestCulture = new RequestCulture("en-US");
 
        var cultures = new CultureInfo[]
        {
            new CultureInfo("en-US"),
            new CultureInfo("de-DE"),
            new CultureInfo("fr-FR")
        };
 
        options.SupportedCultures = cultures;
        options.SupportedUICultures = cultures;
    });
}

The localization middleware must be enabled using the UseRequestLocalization method as the last configuration step.

app.UseRequestLocalization();

The RequestLocalizationOptions object we configured above is initialized by the UseRequestLocalization method. RequestCultureProvider is a concept in the RequestLocalizationOptions that decides the culture information in each request. We will cover these providers in greater detail later in this tutorial. The RequestLocalizationOptions class configures the QueryStringRequestCultureProvider, CookieRequestCultureProvider, and AcceptLanguageHeaderRequestCultureProviders as default providers. The list of RequestCultureProvider is enumerated when requests arrive at the server, and the first provider that can successfully identify the request culture is used. The DefaultRequestCulture property setting will be used in the event that none of the providers are able to identify the request culture.

options.DefaultRequestCulture = new RequestCulture("en-US");

The foundational localization settings for our application are now set up. The location and naming guidelines for the resource files must be chosen next.

Resource Files Naming Conventions and Location

We can separate the localizable resources, such as strings, icons, images, etc., from the source code by using a resource (.resx) file. We typically include information about the culture in the file name when creating resource files for various languages and cultures. For instance, the file name for a resource file to store resources in English would be MyResourceFile.en.resx. The file name will be MyResourceFile.en-US.resx if you want to make a separate resource file for US English. You can right-click on the folder where you want to create the resource file and select Add > New Item from the menu in Visual Studio to create a new resource file.

The full type name of the class is used by ASP.NET Core localization to find the resource files in the project. For instance, the resource file name would be as follows if we were to create French language resources for the HomeController of our AspNetCoreLocalizationDemo application.

AspNetCoreLocalizationDemo.Controllers.HomeController.fr-FR.resx

Another strategy is to save the resource file next to the HomeController class with the name HomeController.fr-FR.resx. The English, French, and German resource files that were created alongside the HomeController class are displayed in the following screenshot.

Please be aware that the ResourcesPath property has been set as follows in the Startup.cs file’s ConfigureServices method:

options.ResourcesPath = "Resources";

It implies that we can now create the Resources folder and place all resource files in it in the project root folder. The resource files can also be organized using nested folders with the same naming patterns. For instance, we could make a Controllers folder inside the Resources folder and move the three HomeController-related resource files there.

Depending on how you want to organize your resource files, you can either use the dot naming convention or copy the file path. If you want to mimic the path, your resource file will be located at Resources/Controllers/HomeController.en-US.resx, whereas if you want to use the dot naming convention, you will name your file as Resources/Controllers.HomeController.en-US.resx.

Let’s add some string resources to the three resource files by opening them all. The two English language string resources added to the HomeController.en-US.resx resource file are shown in the following screenshot.

The following screenshot shows the two French language string resources added in HomeController.fr-FR.resx resource file.

The following screenshot shows the two English language string resources added in HomeController.de-DE.resx resource file.

Introducing .NET Core Localizer Services

Localized services are a new concept introduced by.NET Core to increase developer productivity. These services can give you access to the resources saved in resource files and can be injected using dependency injection. These are the three localizer services:

1. IStringLocalizer or IStringLocalizer<T>
2. IHtmlLocalizer or IHtmlLocalizer<T>
3. IViewLocalizer

Using IStringLocalizer Service

A service that offers localized strings is represented by IStringLocalizer. As shown in the code snippet below, let’s inject the IStringLocalizerT> into the application’s HomeController.

HomeController.cs

public class HomeController : Controller
{
    private readonly IStringLocalizer<HomeController> _stringLocalizer;
 
    public HomeController(IStringLocalizer<HomeController> stringLocalizer)
    {
        _stringLocalizer = stringLocalizer;
    }
 
    public IActionResult Index()
    {
        ViewData["PageTitle"] = _stringLocalizer["page.title"].Value;
        ViewData["PageDesc"] = _stringLocalizer["page.description"].Value;
 
        return View();
    } 
}

When the localizer is ready, you can use its indexer to retrieve the localized strings from the resource file that correspond to the current cultural context. Using the keys page.title and page.description, we are retrieving localized strings in the aforementioned example and storing them in a ViewData object. In our razor view, we can then access this ViewData object and display the localized strings as displayed in the example below.

Index.cshtml

<div class="text-center">
    <h1 class="display-4">
        @ViewData["PageTitle"]
    </h1>
    <p>
        @ViewData["PageDesc"]
    </p>
</div>

If you run the application, the localized strings in English will appear on the page.

By directly injecting the IStringLocalizerT> into your razor views, as shown in the following code snippet, you can avoid having to pass strings from controllers to views using the ViewData object and cut down on some of the code from the above example.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @Localizer["page.description"]
    </p>
</div>

Using IHtmlLocalizer Service

Let’s introduce the HTML bold tag to your string to add some HTML content, as seen in the screenshot below.

You will notice that the browse does not display the formatted string if you run the application right away. This is due to the IStringLocalizer’s inability to encode the HTML that is present in the strings. Utilize IHtmlLocalizer, which will HTML-encode the resource string’s HTML characters but not the resource string itself.

The injection and use of IHtmlLocalizer are very similar to those of IStringLocalizer. The following shows how IHtmlLocalizer is used in the razor view.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
@inject IHtmlLocalizer<HomeController> HtmlLocalizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @HtmlLocalizer["page.description"]
    </p>
</div>

Restart the application, and the word “home page” should appear bold this time.

Using IViewLocalizer Service

A view receives localized strings from the IViewLocalizer service. The naming convention and location of the resource files become even more crucial when we use the IViewLocalizer service. This is so that the resource file can be located using the view file name rather than the default implementation of IViewLocalizer. This also implies that IViewLocalizer cannot use the global shared resource files.

Create a resource file called Index.en-US.resx at the ResourcesViewsHome folder with the name Index.razor since our view file’s name is Index.razor, as shown in the following screenshot.

For demonstration purposes, let’s add a different string in the Index.en-US.resx file.

To use IViewLocalizer, inject it in the Index.cshtml file as shown in the code snippet below.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
@inject IHtmlLocalizer<HomeController> HtmlLocalizer
@inject IViewLocalizer ViewLocalizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @HtmlLocalizer["page.description"]
    </p>
    <p>
        @ViewLocalizer["view.breadcrumb.text"]
    </p>
</div>

When you rerun the application, you should see the words “Home – Index” displayed on the page thanks to the IViewLocalizer service.

You can add more languages and set any language as your default language if you’re using the Chrome browser by going to Settings. For instance, I added the German language to the screenshot below and instructed the Chrome browser to display everything in German.

Run your application right away to see the translated strings from the German language resource file displayed on the page.

Overview of Default Request Culture Providers

There are some request culture providers included right out of the box when we configure and use the request localization in.NET Core. In our application, we have the option to either use these default providers or define our own unique request culture provider. The list of default request culture providers is provided below.

1. AcceptLanguageHeaderRequestCultureProvider
2. QueryStringRequestCultureProvider
3. CookieRequestCultureProvider

AcceptLanguageHeaderRequestCultureProvider

Web browsers automatically send the client culture along with each request using the Accept-Header, which is typically set to the user’s native language. The tools in the Chrome browser make it simple to see this header and its value. For instance, because I added the German language in the earlier section, my browser is currently displaying both en-US and de-DE.

QueryStringRequestCultureProvider

To override the culture, you can pass a query string to this provider. Because the query string’s culture value can be changed, developers can quickly test or debug various cultures. Culture and ui-culture parameters can be passed to the query string provider. One of the two culture or ui-culture values may be passed in place of the other, and the query string provider will set both values using that value. By including fr-FR in the query string, let’s test this provider in our application. You’ll notice that the page’s contents are converted to French strings right away.

Let’s change the value to de-DE and the page contents will update accordingly.

CookieRequestCultureProvider

To establish the culture, most production apps typically use cookies. The cookie with the name is used by the CookieRequestCultureProvider.AspNetCore.Culture by default, and you can use the tools in your browser to see how the cookie value is formatted. c=%LANGCODE%|uic=%LANGCODE%, where c stands for Culture and uic for UICulture, is the cookie format.

Switching Language in ASP.NET Core Applications

Now that we are aware of the standard methods for changing the ASP.NET Core application culture, such as Accept-Header, the query string, and cookies, let’s build a sample demo that will give the application’s end user the option to switch to a different language at runtime using one of the standard methods mentioned above. To display supported cultures in a dropdown at the top of the page, we must first obtain the list of supported cultures. The following code snippet should be added to the top of the _Layout.cshtml file after opening it.

_Layout.cshtml

@using Microsoft.AspNetCore.Builder
@using Microsoft.AspNetCore.Localization
@using Microsoft.Extensions.Options
 
@inject IOptions<RequestLocalizationOptions> LocOptions
 
@{
    string returnUrl = ViewContext.HttpContext.Request.Path;
 
    var requestCulture = Context.Features.Get<IRequestCultureFeature>();
    var cultureItems = LocOptions.Value.SupportedUICultures
        .Select(c => new SelectListItem { Value = c.Name, Text = c.DisplayName })
        .ToList();
}

Access to the collection of feature interfaces for the current request is made possible by the HttpContext’s Features property. We are particularly interested in the IRequestCultureFeature, which stands for the feature that conveys details about the culture of the active request.

var requestCulture = Context.Features.Get<IRequestCultureFeature>();

We are using the RequestLocalizationOptions object to retrieve the complete list of supported cultures that we configured in the Startup.cs file at the beginning of this post. In order to bind the SelectListItem with the HTML select control, we are also creating a SelectListItem from the list of SupportedUICultures.

var cultureItems = LocOptions.Value.SupportedUICultures
        .Select(c => new SelectListItem { Value = c.Name, Text = c.DisplayName })
        .ToList();

The asp-items property will be used to link the HTML select dropdown with the cultures in the form that will be added to the top navigation bar. To ensure that the current culture is pre-selected automatically on page refresh, the current culture name is also bound with the asp-for property. Additionally, I automated the submission of the form to the ChangeLanguage action method, which will perform all the magic for us, using the onchange event.

<ul class="navbar-nav flex-grow-1">
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Index">Home</a>
    </li>
 
    <li class="nav-item">
        <form asp-action="ChangeLanguage" asp-controller="Home" method="post">
 
            <input type="hidden" id="returnUrl" name="returnUrl" value="@returnUrl" />
 
            <select id="culture"
                name="culture"
                class="form-control"
                onchange="this.form.submit();"
                asp-items="cultureItems"
                asp-for="@requestCulture.RequestCulture.UICulture.Name">
            </select>
 
        </form>
    </li>
</ul>

The primary function of the HomeController class’s ChangeLanguage action method is to create a cookie with the currently selected culture and add it to the HTTP response cookies collection. It takes the culture and returnUrl as parameters.

[HttpPost]
public IActionResult ChangeLanguage(string culture, string returnUrl)
{
    Response.Cookies.Append(
        CookieRequestCultureProvider.DefaultCookieName,
        CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(culture)),
            new CookieOptions
            {
                Expires = DateTimeOffset.UtcNow.AddDays(7)
            }
    );
 
    return LocalRedirect(returnUrl);
}

You only need that one line of code to implement language switching. The page contents will be automatically translated to French when you launch the application and choose French from the dropdown.

Now try to select the German language from the dropdown and the page contents will update accordingly.

At this point, if you check the cookies in the browser developer tools, you will see that the culture is currently set to German.

Summary

Many web developers find localization to be a frightening subject, but you will agree with me that ASP.NET Core has made localization incredibly easy to implement. The configuration of multiple languages, the creation of localized string resources, and the use of the default request culture providers were all covered in this post. Additionally, we have mastered the art of dynamic language switching. I sincerely hope this post was helpful to you. Please leave your feedback in the section below if you have any suggestions or comments. Don’t forget to spread the word about this tutorial to your friends and neighbors.

Once a page has been cached in the browser (or proxy), the server cannot make the cached copy be utilized in place of the updated version. Pages that are likely to change cannot, therefore, be cached at the client for very long. There is nothing we can do to change this.

We should have greater control at the server, but sadly, the built-in response caching prevents cache invalidation. Additionally, it employs the same cache duration for asking the browser to cache the page and for server-side caching. Some apps cannot use the built-in response caching due to these limitations.

We are going to investigate developing a unique response caching system. We’ll presum the following conditions:

• Allow server and client cache durations to be different
• Allow an arbitrary page to be removed from the cache at will
• Allow multiple cached pages to be removed based on a common criterion (tags)

The fundamental prerequisite is the capacity for endless caching at the server and the ability for application code to invalidate current cache entries when content changes.

Additionally, we’ll prioritize efficiency and quickness over adaptability. IMemoryCache will be used to implement the cache for a single web server. It is simple to go from using IMemoryCache to IDistributedCache in web farm scenarios, however because of this interface’s less features, the third criteria (tagged) cannot be met without a redesign.

Implementation

We will implement our caching as middleware that runs before MVC and can short-circuit the entire request pipeline if a cached page is found in order to enable it to be as quick as feasible.

We have the following flow for a page that is not in the cache:

1. Fail to retrieve page from the cache
2. Execute inner middleware (the MVC pipeline) redirecting the response to a buffer
3. Cache the page (if conditions are met)
4. Render page

The sequence is substantially shorter for a page that has already been cached:

1. Retrieve page from cache
2. Render page

The quickest way to return cached material is using middleware, but it is more challenging to allow specific page cache setup. The middleware might be utilized independently if all pages were cached using the same criteria, but for the majority of real-world sites, we require the ability to control which pages are cached and for how long. Although middleware configuration might be used, using attributes on controller actions is considerably simpler.

Controlling server caching

We’ll use a very basic action filter attribute to let us manage how specific pages are cached:

public class CacheAttribute : ActionFilterAttribute
{
    public int? ClientDuration { get; set; }
    public int? ServerDuration { get; set; }
    public string Tags { get; set; }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        // validation omitted

        if (ClientDuration.HasValue)
        {
            context.HttpContext.Items[Constants.ClientDuration] = ClientDuration.Value;
        }

        if (ServerDuration.HasValue)
        {
            context.HttpContext.Items[Constants.ServerDuration] = ServerDuration.Value;
        }

        if (!string.IsNullOrWhiteSpace(Tags))
        {
            context.HttpContext.Items[Constants.Tags] = Tags;
        }

        base.OnActionExecuting(context);
    }
}

The filter’s simple implementation only adds the attribute values to the collection of HttpContext Items. To communicate between the operation and the middleware for caching, we are using the collection.

The middleware

The primary Invoke method of the middleware is quite readable:

public async Task Invoke(HttpContext context)
{
    var key = BuildCacheKey(context);

    if (_cache.TryGet(key, out CachedPage page))
    {
        await WriteResponse(context, page);

        return;
    }

    ApplyClientHeaders(context);

    if (IsNotServerCachable(context))
    {
        await _next.Invoke(context);

        return;
    }            

    page = await CaptureResponse(context);

    if (page != null)
    {
        var serverCacheDuration = GetCacheDuration(context, Constants.ServerDuration);

        if (serverCacheDuration.HasValue)
        {
            var tags = GetCacheTags(context, Constants.Tags);

            _cache.Set(key, page, serverCacheDuration.Value, tags);
        }
    }            
}

Your requirements will determine how you construct the cache key, however it may only require the use of context.Request.Path.

The request is finished if the page can be retrieved from the cache and written to the response.

private async Task WriteResponse(HttpContext context, CachedPage page)
{
    foreach (var header in page.Headers)
    {
        context.Response.Headers.Add(header);
    }

    await context.Response.Body.WriteAsync(page.Content, 0, page.Content.Length);
}

If a cached page cannot be located, additional effort must be done. In order to determine if we may cache the request, we first set any necessary client caching headers. If another method is used, we call the following middleware component and stop processing the request because we only wish to cache GET methods.

Capturing the request output from internal middleware components is the next step. In the part after this, we go over how this is accomplished. If we’ve set up server side caching (using the action filter mentioned above), the last step is to save the page to the cache.

Capturing the response

You must replace the response body stream’s default with a MemoryStream in order to capture the page response:

private async Task<CachedPage> CaptureResponse(HttpContext context)
{
    var responseStream = context.Response.Body;

    using (var buffer = new MemoryStream())
    {
        try
        {
            context.Response.Body = buffer;

            await _next.Invoke(context);
        }
        finally
        {
            context.Response.Body = responseStream;
        }

        if (buffer.Length == 0) return null;

        var bytes = buffer.ToArray(); // you could gzip here

        responseStream.Write(bytes, 0, bytes.Length);

        if (context.Response.StatusCode != 200) return null;

        return BuildCachedPage(context, bytes);
    }
}

We return null and make no attempt to cache the response if nothing has been written to it or if the status code is not 200. If not, a CachedPage instance is returned:

internal class CachedPage
{
    public byte[] Content { get; private set; }
    public List<KeyValuePair<string, StringValues>> Headers { get; private set; }

    public CachedPage(byte[] content)
    {
        Content = content;
        Headers = new List<KeyValuePair<string, StringValues>>();
    }
}

The content of the cached page is combined with a subset of the response headers, some of which should be removed (for example, the date header).

Controlling client caching

We choose the straightforward method when it comes to providing caching headers to the browser:

public void ApplyClientHeaders(HttpContext context)
{
    context.Response.OnStarting(() =>
    {
        var clientCacheDuration = GetCacheDuration(context, Constants.ClientDuration);

        if (clientCacheDuration.HasValue && context.Response.StatusCode == 200)
        {
            if (clientCacheDuration == TimeSpan.Zero)
            {
                context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue
                {
                    NoCache = true,
                    NoStore = true,
                    MustRevalidate = true
                };
                context.Response.Headers["Expires"] = "0";
            }
            else
            {
                context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue
                {
                    Public = true,
                    MaxAge = clientCacheDuration
                };
            }
        }

        return Task.CompletedTask;
    });            
}

Keep in mind that our action filter determines the ClientDuration value. There are three possibilities:

• Unset – do not send headers
• Zero – set various headers instructing downstream clients not to cache the response
• Other – set the cache headers to the provided value

The cache

We haven’t yet talked about the actual cache, which is one thing. The _cache references in the code above really correspond to a wrapper class that contains the IMemoryCache implementation that is built-in.

public class CacheClient : ICacheClient
{
    private readonly IMemoryCache _cache;
    
    public CacheClient(IMemoryCache cache)
    {
        _cache = cache ?? throw new ArgumentNullException(nameof(cache));
    }

    internal bool TryGet<T>(string key, out T entry)
    {
        return _cache.TryGetValue(Constants.CacheKeyPrefix + key, out entry);
    }

    internal void Set(string key, object entry, TimeSpan expiry, params string[] tags)
    {
        var options = new MemoryCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = expiry
        };

        var allTokenSource = _cache.GetOrCreate(Constants.CacheTagPrefix + Constants.AllTag, 
            allTagEntry => new CancellationTokenSource());

        options.AddExpirationToken(new CancellationChangeToken(allTokenSource.Token));

        foreach (var tag in tags)
        {
            var tokenSource = _cache.GetOrCreate(Constants.CacheTagPrefix + tag, tagEntry =>
            {
                tagEntry.AddExpirationToken(new CancellationChangeToken(allTokenSource.Token));

                return new CancellationTokenSource();
            });

            options.AddExpirationToken(new CancellationChangeToken(tokenSource.Token));
        }

        _cache.Set(Constants.CacheKeyPrefix + key, entry, options);
    }

Expiration tokens are used by the Set function to enable bulk removal of cache entries.

The concept is that we store a CancellationTokenSource for every entry in the cache and additional CancellationTokenSources for each tag we define. If you have never used CancellationTokenSource before, this may be a little difficult to understand. When setting the cache entry, we produce a token by using these CancellationTokenSources. In the following part, we’ll look at using the CancellationTokenSources to invalidate cache items in bulk.

Cache invalidation AKA cache busting

This unique kind of response caching was implemented primarily to meet the need for the ability to delete cache items before they naturally expire. The following methods are exposed by our CacheClient class for this:

public void Remove(string key)
{
    _cache.Remove(Constants.CacheKeyPrefix + key);
}

public void RemoveByTag(string tag)
{
    if (_cache.TryGetValue(Constants.CacheTagPrefix + tag, out CancellationTokenSource tokenSource))
    {
        tokenSource.Cancel();

        _cache.Remove(Constants.CacheTagPrefix + tag);
    }            
}

public void RemoveAll()
{
    RemoveByTag(Constants.AllTag);
}

As you can see, deleting a single cache entry just requires that you know the key. You could want to allow action, controller, and route values to be given instead to make it more user-friendly.

The RemoveAll and RemoveByTag methods invoke the Cancel() function, which expires all tokens issued by the source, after retrieving the CancellationTokenSource from the cache. These cache entries are eliminated as a result.

Limitations

This is a very simple illustration of response caching and is devoid of many features found in native response caching middleware. The lack of the option to alter caching depending on headers, cookies, etc. is perhaps the most noticeable missing. It would not be extremely challenging to incorporate VaryBy. In reality, all we’re altering is how the cache key is generated and adding support for CacheAttribute setting.

Additionally, we are using IMemoryCache rather than IDistributedCache, which is more scalable. As was already said, modifying the usage is simple but will reduce functionality. Since IDistributedCache does not allow expiration tokens, the method described here cannot be used to remove pages in bulk. Naturally, nothing prevents you from coming up with a different approach, but unsophisticated implementations will almost surely have a negative impact on performance.

Summary

The creation of simple response caching middleware that enables manual invalidation of items both individually and in bulk using tags was covered in this post. To store pages (or other action results like JSON) in an in-memory cache, we combined an action filter with a middleware component. Then, we made a number of methods available on our CacheClient class to enable the deletion of cache entries.

The example code should not be used in place of the built-in response caching, which offers far more capability, although it might be helpful in some circumstances.

IIS, on the other hand, is a web server that utilizes the Windows OS and the ASP.NET framework. IIS’s function in this situation is to host ASP.NET Core-built apps.

In this article, we’ll look at how to integrate ASP.NET Core with IIS. Let’s examine the procedures for deploying ASP.NET Core to IIS without further ado.

How to Setup an ASP.NET Core Application for IIS

When starting a new ASP.NET Core project, you will immediately discover that it is a console application. The following code is also present in your project’s Program.cs file, which is similar to a console application:

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

        host.Run();
    }
}

What is the WebHostBuilder?

A WebHost object—essentially the application and web server—is necessary for all ASP.NET Core applications. To configure and create the WebHost in this instance, a WebHostBuilder is utilized. Usually, the setup code for WebHostBuilder contains the statements UseKestrel() and UseIISIntegration().

Why do these?

• UseKestrel() – Registers Kestrel as the server that will host your application by registering the IServer interface. Other solutions, such as the Windows-only WebListener, may become available in the future.
• UseIISIntegration() – Provides information to ASP.NET about how IIS will act as a reverse proxy in front of Kestrel, including the port it should listen on, forward headers, and other parameters.

If you are planning to deploy your application to IIS, UseIISIntegration() is required

What is AspNetCoreModule?

You may have noticed that ASP.NET Core projects create a web.config file. This is only used when deploying your application to IIS and registers the AspNetCoreModule as an HTTP handler.

Default web.config for ASP.NET Core:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
        </handlers>
        <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
     </system.webServer>
</configuration>

All incoming traffic to IIS is handled by AspNetCoreModule, which then serves as a reverse proxy that knows how to send traffic to your ASP.NET Core application. Its source code is accessible on GitHub. Additionally, AspNetCoreModule is in charge of launching your process and making sure that your web application is up and running.

Install .NET Core Windows Server Hosting Bundle

Installing the.NET Core hosting bundle for IIS, which includes the ASP.NET Core module for IIS and the.NET Core runtime, is necessary before you publish your application.

To make sure all the modifications are taken up by IIS after installation, you might need to do a “net stop was /y” and “net start w3svc” command.

Download: Windows Server Hosting for.NET Core – Select “Windows Server Hosting” without a doubt.

4 Steps to Deploy ASP.NET Core to IIS

Before you deploy, you need to make sure that WebHostBuilder is configured properly for Kestrel and IIS. Your web.config file should also exist and look similar to our example above.

1. Publish to a File Folder

2. Copy Files to Preferred IIS Location

Copy your publish output now to the location where you want the files to reside. You might want to zip up the files and transfer them to the server if you are deploying to a distant host. You can replicate them locally if you are deploying to a local development box.

I’m moving the files to C:\inetpub\wwwroot\AspNetCore46 for our example.

There is no bin folder with ASP.NET Core, and it might copy over a huge number of various.NET DLLs, as you will notice. If you are aiming for the entire.NET Framework, your application might also be an EXE file. Over 100 DLLs were produced by this tiny sample project.

3. Create Application in IIS

Creating your application in IIS is listed as a single “Step,” but you will actually do several different tasks. First, build a new IIS Application Pool with “No Managed Code” for the.NET CLR. IIS isn’t actually running any.NET code; it just functions as a reverse proxy.

The second option is to create your application under an already-existing or brand-new IIS Site. In any case, you must select your new IIS Application Pool and direct it to the location where you copied the ASP.NET publish output files.

4. Load Your Application

At this point, your application should load just fine. If it does not, check the output logging from it. Within your web.config file you define how IIS starts up your ASP.NET Core process. Enable output logging by setting stdoutLogEnabled=true. You may also want to change the log output location as configured in stdoutLogFile. Check out the example web.config before to see where they are set.

Where Can I Find Reliable and Cheap ASP.NET Core Hosting?

The following is my recommendation for ASP.NET Core web hosting:

1. ASPHostPortal: this is my first recommendation to host ASP.NET core website. It is a very reliable platform with a fast server and great customer support. It is a reliable ASP.NET Core hosting service for websites that do not require any special functionality or features.

2. HostForLIFE.eu: HostForLIFE is one of the best ASP.NET core web hosting in Europe. They support all ASP.NET version, start from Classic ASP, ASP.NET 1/2.0/3.5/4.0/4.5 and latest ASP.NET Core version. It is easy to deploy ASP.NET core website to their server.

3. UKWindowsHostASP.NET: One of the most reputable and affordable ASP.Net Core hosting companies in the world is UKWindowsHostASP.NET. It provides cloud hosting, VPS hosting, dedicated servers, and a wide range of adaptable alternatives for your company needs.

4. WindowsASPNETHosting.in: The finest host for developers and new businesses is WindowsASPNETHosting.in. For your web application or other project, WindowsASPNETHosting.in provides an ASP.NET, ASP,.Net Core, and SQL platform that you can easily extend with additional functionality.

5. DiscountService.biz: DiscountService committed to provide best, cheap, and reliable ASP.NET Core hosting services. They can offer you the quickest and safest platform to host your ASP.NET websites.

Conclusion

I hope above article can help you to publish your ASP.NET Core website easily to IIS. Instead of that, I also give some recommendation for ASP.NET core hosting in case you want to publish your ASP.NET core website online. Hope this helps and stay tune with other interesting tutorial and tips. Thank you for reading.

Please make sure you have installed

• The latest version of Visual Studio
• SQL Server

Steps to Create SOAP Demo Application

1. Create a SOAP Webservice in Visual Studio 2019

1. Create an empty ASP.NET Web Application(.NET Framework) .We will use this project as the soap service demo .To do that just follow the steps below.

• Select File > New > Project.
• Select ASP.NET Web Application(.NET Framework). Name the project SoapDemo to have the same namespace as my project. Click Create.
• Select an Empty ASP.NET Web Application(.NET Framework).
• Lastly, Click on Create.

This is what your solution with an empty template would look like after creating a new project. See the picture below.

2. Add a new item by right-clicking your project solution and select Add » NewItem. Then search for Web Service ASMX.

using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Web;
 namespace SoapDemo.Models
 {
         public class ResponseModel
         {
             public T Data { get; set; }
             public int resultCode { get; set; }
             public string message { get; set; }
         }
 }

2. Next, open the SoapDemo.asmx file and insert the example login validation method that is provided below. With this approach, the User table will be searched for the email and password. This method will return the response code, which is described as follows, once the user has been located in the database.

You can choose any response you want to use, but for this example I’m going to use the response code from above. I utilized the database from my earlier tutorial for this example. To construct your own ASP.NET Core login application, click the link below.

You can copy the code snippet below on your SoapDemo.asmx file.

     [WebMethod]
         public  ResponseModel<string> login(string email, string password)
         {
             ResponseModel<string> response = new ResponseModel<string>();
  
             if (email != null)
             {
                 using (SqlConnection conn = new SqlConnection(@"Server=CODERSIGN\SQLEXPRESS01;Database=IdentityDemo;User Id=freecode;Password=freespot;"))
                 {
                     SqlCommand cmd = new SqlCommand("sp_loginUser",conn);
                     cmd.CommandType = CommandType.StoredProcedure;
                     cmd.Parameters.Add("@email", SqlDbType.NVarChar, 50).Value = email;
                     cmd.Parameters.Add("@password", SqlDbType.NVarChar, 50).Value = password;
                     
  
                     SqlDataAdapter da = new SqlDataAdapter(cmd);
                     DataTable dt = new DataTable();
                     da.Fill(dt);
  
  
                     if (dt.Rows.Count > 0)
                     {
                         response.Data = JsonConvert.SerializeObject(dt);
                         response.resultCode = 200;
                     }
                     else
                     {
                         response.message = "User Not Found!";
                         response.resultCode = 500;
                     }
  
  
                 }
             }
             return response;
         } 

3. Now, run your project and make sure you see the method you just created. See the image below.

Soap Service URL: https://localhost:44399/SoapDemo.asmx

3. Create a Sample ASP.NET Core Web Application Project.

This is a sample login application that uses cookie authentication

After that open the project using the latest Visual Studio and rebuild the solution.

4. Add a soap service reference for the ASP.NET Core application’s SoapDemo service.

Now, we are ready to consume the soap service that we created above. Run your soap service and follow the steps below.

1. Run your soap service, this will open the browser with the soap service URL. In my case my soap URL is https://localhost:44399/SoapDemo.asmx.

2. Now, navigate to IdentityDemo project solution. Then right click on the Connected Services then Add Connected Service.

3. Select Microsoft WCF Web Service Reference Provider from Other Services option. Then Input your URL and assign the service name.

4. Then click Finish. This will generate references for your Soap Service.

At this point, we have successfully generated the reference for our Web service project.

5. Consume Soap Service on ASP.NET Core Application

Let’s include the Service’s implementation in our project. We will add the interface and implementation to the existing IRepository and Repository classes as the ASP.NET core is an existing project.

This is a summary of how to obtain an instance of the soap service that we recently implemented.

Before you begin the following actions. The following NuGet packages need be installed.

• System.ServiceModel.Http
• System.ServiceModel.Premitives

1. From IRepository class we added a GetInstanceAsync method. This method will instatiate the soap service.

Task<SoapDemoClient> GetInstanceAsync();

2. Then on the implementation class which is Repository.cs. I added this code.

public readonly string serviceUrl = "https://localhost:44399/SoapDemo.asmx";
public readonly EndpointAddress endpointAddress;
public readonly BasicHttpBinding basicHttpBinding;

Repository Contructor:

 public Repository(IConfiguration configuration)
         {
             _configuration = configuration;
  
             endpointAddress = new EndpointAddress(serviceUrl);
  
             basicHttpBinding = new BasicHttpBinding(endpointAddress.Uri.Scheme.ToLower() == "http" ?
                             BasicHttpSecurityMode.None : BasicHttpSecurityMode.Transport);
             basicHttpBinding.OpenTimeout = TimeSpan.MaxValue;
             basicHttpBinding.CloseTimeout = TimeSpan.MaxValue;
             basicHttpBinding.ReceiveTimeout = TimeSpan.MaxValue;
             basicHttpBinding.SendTimeout = TimeSpan.MaxValue;
         } 

GetInstanceAsync implementation:

 public async Task<SoapDemoSoapClient> GetInstanceAsync()
    {
         return await Task.Run(() => new SoapDemoSoapClient(basicHttpBinding, endpointAddress));
    } 

3. To use this instance you can call it using the code snippet below.

 var client = await GetInstanceAsync();
 var result = await client.loginAsync(loginView.Email, loginView.Password); 

LoginAsync is the Login method from the SoapDemo service that we added on the Connected Service.

This is now the new code in my LoginAsync method.

  public async Task<Response<IdentityModel>> LoginAsync(LoginViewModel loginView)
         {
             Response<IdentityModel> response = new Response<IdentityModel>();
             IdentityModel userModel = new IdentityModel();
  
             try
             {
                 var client = await GetInstanceAsync();
                 var result = await client.loginAsync(loginView.Email, loginView.Password);
  
                 DataTable dt = new DataTable();
                 dt = JsonConvert.DeserializeObject<DataTable>(result.Body.loginResult.Data);
  
                 IdentityModel user = new IdentityModel();
                 user.ID = int.Parse(dt.Rows[0]["ID"].ToString());
                 user.Email = dt.Rows[0]["Email"].ToString();
                 user.Role = dt.Rows[0]["Role"].ToString();
                 user.Reg_Date = dt.Rows[0]["Reg_Date"].ToString();
  
                 response.Data = user;
                 response.message = (result.Body.loginResult.resultCode == 500) ? "Login failed.Please check Username and / or password" : "data found";
                 response.code = result.Body.loginResult.resultCode;
             }
             catch (Exception ex)
             {
                 response.code = 500;
                 response.message = ex.Message;
             } 
  
             return response;
         } 

3. Run and Test

Run the IdentityDemo and SoapDemo projects simultaneously. To create a user for you to log in, utilize the register option. Check out my earlier tutorial to get acquainted with the source code utilized here.

Summary

This lesson taught us how to use Dotnet Core to construct and use Soap Web Services. The ASP.NET core project differs from the ASP.NET MVC project in how a soap service is implemented. We can also see that using Visual Studio 2019 to create a Soap Webservice does not come with a project template for an ASMX project; instead, a new component had to be added manually. I sincerely hope that this tutorial will be useful to you and be incorporated into your future projects.

IApplicationLifetime

There is a IApplicationLifetime interface in ASP.NET Core which can handle events like start up and shut down. It provides 3 Cancellation Token, allowing us to use Action delegate to handle the ASP.NET Core website’s start and stop events:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime appLifetime)
{
    appLifetime.ApplicationStarted.Register(() =>
    {
        _logger.LogInformation("Moonglade started.");
    });

    appLifetime.ApplicationStopping.Register(() =>
    {
        _logger.LogInformation("Moonglade is stopping...");
    });

    appLifetime.ApplicationStopped.Register(() =>
    {
        _logger.LogInformation("Moonglade stopped.");
    });

    // ... Other code
}

Per Microsoft document:

Killing the Website

Besides these 3 events, IApplicationLifetime interface got another method named StopApplication() which can stop the current ASP.NET Core application. When the website is being stopped, ApplicationStopping and ApplicationStopped events will be fired in sequence.

We can restart our website based on this method.

Implement Restart Functionality

The most easy way for us to restart a website is to access a certain URL. Take ASP.NET Core MVC application for example:

Inject an IApplicationLifetime class into the Controller:

public class AdminController : Controller
{
    IApplicationLifetime applicationLifetime;

    public AdminController(IApplicationLifetime appLifetime)
    {
        applicationLifetime = appLifetime;
    }

    // ...
}

And use an Action to invoke the StopApplication() method:

[HttpGet("blow-me-up")]
public IActionResult BlowMeUp()
{
    applicationLifetime.StopApplication();
    return new EmptyResult();
}

Now, when I access the URL “blow-me-up“, the website will shut down itself:

To restart the application is easy. Under IIS, the next request goes to the website will start it up again. Which basically means, reopen the website in the browser again and it will start up.

STEP 1: THE NUGET PACKAGES

You need the following packages:

• Microsoft.Extensions.Logging
• Serilog.Extensions.Logging.File

STEP 2: THE CONFIGURATION

This will configure the logging:

"ApplicationInsights": {
    "InstrumentationKey": "[The instrumentation key]"
  },
"Logging": {
    "PathFormat": "[The path and file format used in file logging, e.g.: c:\\log-{Date}.txt]",
    "LogLevel": {
      "Default": "Information"
    },
    "ApplicationInsightsLoggerProvider": {
      "LogLevel": {
        "Default": "Warning"
      }
    }
  }

The “Logging” section configures the different log levels for file and Application Insights.

STEP 3: THE EXTENSION METHOD

This method allows you to add logging easily:

using Microsoft.ApplicationInsights.AspNetCore.Extensions;
 
namespace MyCode
{
    public static class WebApplicationBuilderExtensions
    {
        public static void AddLogging(this WebApplicationBuilder builder)
        {
            // Add file logging
            builder.Host.ConfigureLogging(logging =>
                {
                    logging.AddFile(builder.Configuration.GetSection("Logging"));
                }
            );
            // Add Application Insights Logging
            var options = new ApplicationInsightsServiceOptions();
            options.InstrumentationKey = builder.Configuration["ApplicationInsights:InstrumentationKey"];
            builder.Services.AddApplicationInsightsTelemetry(options);
        }
    }
}

STEP 4: CALL THE METHOD WHEN BUILDING YOUR APPLICATION

This is an example where I configure my logging:

using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;
 
var webApplicationOptions = new WebApplicationOptions();
var builder = WebApplication.CreateBuilder(webApplicationOptions);
builder.AddLogging();
...
...
...
builder.Build();

Use HTTPS Redirection

I guess that the first idea that comes to your mind is to redirect HTTP requests: if a client calls your application using HTTP, your application redirects it to the same URL starting with HTTPS. URL redirection is a well-known approach. The web application creates an HTTP response with a status code starting with 3 and a Location header like in the following example:

HTTP/1.1 301 Moved Permanently
Location: https://www.topreviewhostingasp.net/

While this approach doesn’t resolve all the security risks, as you will learn along the way, it’s a good starting point.

Fortunately, in ASP.NET Core, you don’t need to go to the HTTP level to redirect your client’s requests. You have a few options to choose from. Let’s analyze each of them.

The RequireHttps attribute

The first approach we’ll explore is based on the RequireHttps attribute. You can use it in your Razor Pages applications to force a page to require HTTPS, as shown in the following code snippet:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace RazorApp.Pages;

[RequireHttps]
public class PrivacyModel : PageModel
{
  //...existing code...
}

If this page is called through HTTP, an HTTPS redirection response will be automatically created for you. For Razor Pages, you can apply the RequireHttps attribute only to classes inheriting from PageModel. You cannot apply the attribute to the class methods as well.

In ASP.NET Core MVC applications, you can apply the RequireHttps attribute to classes inherited from Controller, as in the following example:

using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using MvcApp.Models;

namespace MvcApp.Controllers;

[RequireHttps]
public class HomeController : Controller
{
  // ...existing code...
}

When the attribute is attached to the controller, the HTTP redirection is applied to any view returned by it. However, in the ASP.NET Core MVC case, you can apply the RequireHttps attribute to specific views. For example, the following code shows how to require HTTPS redirection only for the Privacy view:

using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using MvcApp.Models;

namespace MvcApp.Controllers;

public class HomeController : Controller
{
    public IActionResult Index()
    {
        return View();
    }

    [RequireHttps]
    public IActionResult Privacy()
    {
        return View();
    }
}

The redirection approach based on the RequireHttps attribute is pretty simple. You may also think that the opportunity to apply it selectively to specific pages or views is great because you can limit HTTPS to just pages with confidential content.

Actually, mixing HTTP and HTTPS pages is a really bad idea! Your web application is not secure because it is exposed to HTTPS downgrade attacks. To mitigate this risk, make all your web application’s pages accessible only with the HTTPS protocol.

You may think of applying the RequireHttps attribute to all the pages to reduce the risk, but there are better approaches, as you will see in the next section.

The HTTPS redirection middleware

When you create a web application using one of the standard ASP.NET project templates, the Program.cs file contains the method invocation highlighted in the following code snippet:

// Program.cs

var builder = WebApplication.CreateBuilder(args);

// ...existing code...

var app = builder.Build();

// ...existing code...

app.UseHttpsRedirection();  //? HTTPS redirection
app.UseStaticFiles();

app.UseRouting();

// ...existing code...

The UseHttpsRedirection() method invocation enables the HTTPS redirection middleware. This means that each request to your application will be inspected and possibly redirected by the middleware. You don’t need to look for pages missing the RequireHttps attribute. All the pages of your application will require HTTPS. If a client requests a page with HTTP, it will be automatically redirected to the corresponding HTTPS-based URL.

Enable the HSTS middleware

The approach based on UseHttpsRedirection() looks awesome! With just one statement in your Program.cs file, your entire web application is forced to be called with the HTTPS protocol.

Unfortunately, while this approach is better than having mixed pages, there are still some potential security issues with your application. Forcing a client to switch from HTTP to HTTPS on each request might not be enough to prevent HTTPS downgrade attacks. The attacker could intercept the client’s HTTP request before it switches to the corresponding HTTPS request.

You need a way to tell the browser to mandatorily use HTTPS to request any resource of your web application. This way exists: the HTTP Strict-Transport-Security header (HSTS). Using HSTS, the browser will call your application using HTTP only the very first time. The subsequent requests against the same domain will be made using the HTTPS protocol, even in the presence of a URL using the HTTP scheme.

To enable HSTS in your ASP.NET Core application, you just need to invoke the UseHsts() method in your Program.cs file as shown below:

// Program.cs

var builder = WebApplication.CreateBuilder(args);

// ...existing code...

var app = builder.Build();

// ...existing code...

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();    //? Enable HSTS middleware
}

// ...existing code...

By invoking the UseHsts() method, you enable the HSTS middleware. You have this code already in your application when you build it by starting from a standard ASP.NET Core template.

Using HSTS in the development environment

From the code above, you may notice that the HSTS support is enabled only if your application is not running in your development environment. There is a practical reason behind this choice.

Chances are that you use localhost as your development environment domain. If you use HSTS in your development environment, any request made by your browser to localhost will use HTTPS. Actually, using HTTPS in your development environment is a good practice. But suppose your ASP.NET Core application enables HSTS. In that case, it causes your browser to make HTTPS requests to any application hosted on localhost, not just your ASP.NET Core application and not just ASP.NET Core applications in general. This may lead to headaches in case you have, say, an Angular application that doesn’t use HTTPS and stops working overnight.

HSTS settings include an expiration time, which by default is 30 days for ASP.NET Core applications. To change this and other settings, check out the official documentation.

HTTPS Redirection and APIs

At this point, we can feel happy with the HTTPS security of our ASP.NET Core application, right? Well, not really. Actually, it depends on the type of web application.

The HTTPS redirection approach relies on sending back to the client a 301 or another 30* HTTP status code, regardless you are using the RequireHttps attribute or the HTTPS redirection middleware. The HSTS approach relies on sending the Strict-Transport-Security header.

Both approaches are well-understood by standard browsers. So, application types whose clients are browsers, such as ASP.NET Core MVC applications, Razor Pages applications, and Blazor Server applications, can rely on these approaches.

However, those approaches are usually ignored by non-browser clients, such as API clients. It’s extremely rare for a mobile app or a SPA to take care of 301 status codes or HSTS headers. In this case, you have two alternative ways to deal with clients that make HTTP requests:

• Ignore HTTP requests.
• Respond with a 400 Bad Request status code.

Ignore HTTP requests

The first option can be done in different ways. One of the easiest ways is to use the --urls flag of the dotnet run command, as shown below:

dotnet run --urls "https://localhost:7123"

This approach allows you to override the URL settings configured in the Properties/launchSettings.json file of your ASP.NET Core project.

A more production-oriented approach to override those settings uses the ASPNETCORE_URLS environment variable. The following shows how to set this variable in PowerShell:

$Env: ASPNETCORE_URLS = "https://localhost:7123"

This is an example in a bash shell:

export ASPNETCORE_URLS="https://localhost:7123"

Treat HTTP requests as bad requests

To implement the Bad Request approach, you need to create a custom middleware and use it instead of HTTPS redirection and HSTS middleware. The following example shows a simple version of such a middleware:

// Program.cs

var builder = WebApplication.CreateBuilder(args);

// ...existing code...

var app = builder.Build();

// ...existing code...

// ? new code
//app.UseHttpsRedirection();
app.Use(async (context, next) => {
    if (!context.Request.IsHttps) {
        context.Response.StatusCode = StatusCodes.Status400BadRequest;
        await context.Response.WriteAsync("HTTPS required!");
    } else {
        await next(context);
    }
});
/ ? new code
  
app.UseStaticFiles();

app.UseRouting();

// ...existing code...

The highlighted code shows that the existing UseHttpsRedirection() method invocation is replaced by the custom middleware. The middleware’s code just checks if the current request uses HTTPS. If this is not the case, it replies with a 400 Bad Request status code and a message warning that HTTPS is required.

HTTPS Redirection and Reverse Proxies

All the above makes sense if your ASP.NET Core application is directly exposed to the Internet. If your application is deployed in an environment with a reverse proxy that handles connection security, there is no need to use HTTPS redirection or HSTS middleware.

In this case, you can simply remove the UseHttpsRedirection() and the UseHsts() method calls from your ASP.NET Core applications. The same applies to ASP.NET Core Web API application as well: you don’t need to create a custom middleware to deny HTTP requests. You delegate HTTP to HTTPS switching and control to the reverse proxy.

Summary

This article guided you through the different approaches to force a client to use HTTPS when it calls an ASP.NET Core application. You started from the simple RequireHttps attribute, which redirects to HTTPS-based requests on a page-by-page basis. You then explored the UseHttpsRedirection() method, which allows you to apply HTTPS redirection to all your application’s pages.

You learned that redirecting from HTTP to HTTPS at each page request doesn’t guarantee you are not exposed to HTTPS downgrade risks. You took a further step in mitigating this risk by learning about HSTS and the UseHsts() method.

You also learned that HTTPS redirection and HSTS are great approaches for regular web applications, such as ASP.NET Core MVC, Razor, and Blazor applications, but they are not suitable for APIs. In this case, you need to ignore HTTP requests or mark them as bad requests.

Finally, you only need to apply all these measures if your deployment environment doesn’t take care of protocol switching and control. For example, if your application runs behind a reverse proxy, you can delegate all these checks to it.