This article will teach you how to embed a plain text file in a PDF document and how to extract the attachment from it.

Adding Attachments

This sample code demonstrates how TX Text Control can be used to attach a text file to a PDF document.

        // create a non-UI ServerTextControl instance
using (TXTextControl.ServerTextControl tx = new TXTextControl.ServerTextControl()) {

  tx.Create();
  // set dummy content
  tx.Text = "PDF Document Content";

  // read the content of the attachment
  string sAttachment = System.IO.File.ReadAllText("attachment.txt");

  // create the attachement
  TXTextControl.EmbeddedFile attachment =
     new TXTextControl.EmbeddedFile(
        "attachment.txt",
        sAttachment,
        null) {
       Description = "My Text File",
       Relationship = "Unspecified",
       MIMEType = "application/txt",
       CreationDate = DateTime.Now,
     };

  // attached the embedded file
  tx.DocumentSettings.EmbeddedFiles =
     new TXTextControl.EmbeddedFile[] { attachment };

  // save as PDF/A
  tx.Save("document.pdf", TXTextControl.StreamType.AdobePDFA);
}

The attached file is represented by the EmbeddedFile object. The constructor accepts the file name, data, and additional meta data. In addition, the MIME type of the attachment (application/text in this case), a textual description, a relationship, and the creation date are provided.

The relationship is an optional string that describes the relationship between the embedded file and the containing document. It can be a predefined value or adhere to the rules for second-class names (ISO 32000-1, Annex E). Predefined values include “Source”, “Data”, “Alternative”, “Supplement”, and “Unspecified”.

When you open the document in Adobe Acrobat Reader, the attachment will appear in the Attachments side panel.

Extracting Attachments

The code below loads the created PDF file in order to locate the attachment by looping through all embedded files. The found attachment is extracted and saved as a text file.

// create a non-UI ServerTextControl instance
using (TXTextControl.ServerTextControl tx = new TXTextControl.ServerTextControl()) {

  tx.Create();

  // load the PDF document
  TXTextControl.LoadSettings ls = new TXTextControl.LoadSettings();
  tx.Load("document.pdf", TXTextControl.StreamType.AdobePDF, ls);

  // read the attachments
  TXTextControl.EmbeddedFile[] files = ls.EmbeddedFiles;

  // find the specific attachment and save it
  foreach(TXTextControl.EmbeddedFile file in files) {
    if (file.Description == "My Text File") {
      string sAttachment = Encoding.UTF8.GetString((byte[])file.Data);
      System.IO.File.WriteAllText("attachment_read.txt", sAttachment);

      break;
    }
  }
}

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.

When I was looking at some code, I noticed that the logs were always there, but when I looked closer, I realized that they were frequently irrelevant because they contained little to no significant information. Particularly when there is a problem in the production environment, we often let details that can make a big difference escape due to lack of time, distraction, or ignorance.

In this article, we’ll go over some crucial issues relating to logs and how to use them efficiently while adhering to best practices and making sure they’re pertinent for upcoming data analysis.

1. Log Levels and .NET Logging

The logging severity levels are defined by the C# Enum named LogLevel in the.NET context. The Assembly contains extension methods that provide log level indication. Microsoft.Extensions.Logging.Abstractions.

The table of log levels in.NET Core is shown below.

These are the log levels, and you should use them in the appropriate situations. For each level, there are some real-world examples below.

Usage Examples for Each Level

public class LogService
{
    private readonly ILogger<LogService> _logger;

    public LogService(ILogger<LogService> logger)
    {
        _logger = logger;
    }

    public void ProccessLog()
    {
        var user = new User("John Smith", "smith@mail.com", "Kulas Light", null, null);

        //Trace
        _logger.LogTrace("Processing request from the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Debug
        var zipcodeDefault = "92998-3874";
        if (user.Zipcode == zipcodeDefault)
            _logger.LogDebug("The zip code is default for the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Information
        _logger.LogInformation("Starting execution... - {ProccessLog}", nameof(ProccessLog));


        //Warning
        if (string.IsNullOrEmpty(user.Zipcode))
            _logger.LogWarning("The zip code is null or empty for the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Error
        try
        {
            var zipcodeBase = "92998-3874";
            var result = false;

            if (user.Zipcode == zipcodeBase)
                result = true;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex.Message, "Error while processing request from the user: {Name} the zipcode is null or empty. - {ProccessLog}", user.Name, nameof(ProccessLog));
        }


        //Critical
        try
        {
            var userPhone = user.Phone;
        }
        catch (Exception ex)
        {
            _logger.LogCritical(ex.Message, "The phone number is null or empty for the user: {Name}. Please contact immediately the support team! - {ProccessLog}", user.Name, nameof(ProccessLog));
            throw;
        }


        //None
        //Not used for writing log messages
    }
}

2. Logging Frameworks or Libraries

The functions in Microsoft Logging Assembly can be used on any system, no matter how big or small, and they satisfy the fundamental requirements for logging. However, some situations call for more customizable logs and detailed logs. The development community is aware of and accepts libraries as being helpful in these situations.

Here are some usage examples for Serilog, one of the more well-known libraries.

Serilog

The log library that has been downloaded most frequently from the NuGet website is Serilog. Serilog NuGet is where you can find it.

Serilog offers diagnostic logging for files, consoles, and a variety of other locations, just like other libraries. It is simple to configure and has a wide range of features for contemporary applications.

Below, a real-world application of its use will be shown along with some of Serilog’s numerous customization options.

Practical Example

1. Create a new console app with .NET 6.

You can do this through Visual Studio 2022 or via the console with the following command:

public record Offer(int Id, int ProductId, string Description, decimal Value, decimal Quantity);

using Serilog;
using Serilog.Templates;

ExecuteLogs();

void ExecuteLogs()
{
    LogToConsole();
    LogToFile();
}

void LogToConsole()
{
    var offer = FillOffer();

    Log.Logger = new LoggerConfiguration()
     .Enrich.WithProperty("offerId", offer.Id)
     .Enrich.WithProperty("productId", offer.ProductId)
     .Enrich.WithProperty("quantity", offer.Quantity)
     .WriteTo.Console(new ExpressionTemplate("{ {@t, @mt, @l: if @l = 'Information' then undefined() else @l, @x, ..@p} }\n"))
     .CreateLogger();

    Log.Information("Information about the Offer");
}

void LogToFile()
{
    var offer = FillOffer();

    Log.Logger = new LoggerConfiguration()
     .Enrich.WithProperty("offerId", offer.Id)
     .Enrich.WithProperty("productId", offer.ProductId)
     .Enrich.WithProperty("quantity", offer.Quantity)
     .WriteTo.File(new ExpressionTemplate(
         "{ {@t, @mt, @l: if @l = 'Information' then undefined() else @l, @x, ..@p} }\n"),
            "Logs\\log.txt",
                 rollingInterval: RollingInterval.Day)
     .CreateLogger();

    Log.Information("Information about the Offer");
}

Offer FillOffer() =>
        new Offer(5488, 100808, "Book", 109, 3);

And in the folder: “\bin\Debug\net6.0\Logs” is the created file. Inside it will be the same data that was displayed in the console.

In this example we created two methods:

• “LogToConsole()” – It creates an object called “Offer,” then uses a new instance of “LoggerConfiguration” and adds the properties values to logging with the method “Enrich.WithProperty.” Then the method “WriteTo.Console” displays the data logging in the console, and makes the configuration of the template through the class “ExpressionTemplate.”
• “LogToFile()” – It does the same as the previous method, but uses the “WriteTo.File” method to create a “Logs” folder if it doesn’t exist, and inside it a text file that will store the log data. The “rollingInterval” rule determines the interval in which a new file will be created—in this example, one day—that is, the logs will be written to the same file until the day ends, and then a new file will be created.

Serilog was only briefly used in this demonstration, but it has a lot of useful features. Explore them at your leisure.

3. Best Practices and Recommendations

Structured Logs

When an application uses the Microsoft Logging Assembly or more sophisticated filtering to look for logs, the creation of structured logs is advised. The log recording mechanism needs to receive the string containing the placeholders and their values separately, so it is necessary.

Here’s an illustration of a structured log:

_logger.LogWarning( "The zip code is null or empty for the user: {Name}", user.Name;

String interpolation is a viable option, but you should make sure the registration service is set up to still have access to the message template and property values after the replacement.

An illustration of a structured log using string interpolation can be found below:

_logger.LogWarning( $"The zip code is null or empty for the user: {user.Name}";

Enable Only Appropriate Logs in Production

You should take into account the actual requirements for using each of the log levels before publishing something in the production environment. For instance, excessively detailed logs may cause the server to become overloaded or the system to operate slowly.

So, before publishing anything, it’s a good idea to review all the logs and keep only the ones that are pertinent and won’t cause any sort of overhead. In a production setting, trace and debug logs must be disabled.

Using a Third-Party Logging Library

Always ask the client you’re working with if they use a third-party library and what it is before beginning a new project because you don’t want to waste your time on something that won’t be put into production because it uses private property.

Logging Sensitive Information

Never include private or delicate data in production logs, such as user-related information like passwords or credit card numbers, or any data pertaining to something that cannot be made public. Additionally to being accessible to anyone with access to logged data, this information typically lacks any encryption, making it vulnerable to disclosure in the event that a hacker attack is made against the system.

Writing Relevant Log Messages

The presence of a log message at a crucial point in the code does not guarantee that the system is ready for a thorough analysis, as its use would be unnecessary if the message didn’t make much sense in that situation.

Therefore, when writing log messages, consider what would be the most crucial data for a later analysis of the execution. For instance, always include the message produced by the “Catch” method in messages inside exception blocks.

Utilizing the name of the method used when writing the log is another suggestion that can be seen in the example below. In the example below, we are using the command “nameof(ProccessLog)” to record the name of the method that is responsible for execution.

public void ProccessLog()
{
        try
        {
        //execution...
        }
        catch (Exception ex)
        {
 //The exception message "ex.Message" is being used in the log

            _logger.LogError(ex.Message, "Error while processing request from the user: {Name} the zipcode is null or empty. - {ProccessLog}", user.Name, nameof(ProccessLog));
        }
}

Conclusion

We discussed some helpful writing techniques for effective logs in C# and.NET in this article. There are no hard-and-fast guidelines for writing logs; it all depends on the environment in which you are developing. Nevertheless, if you follow these suggestions, your code will undoubtedly get much better.

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.

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.