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.

The safety and security of your data is obviously crucial, so when selecting a web hosting company, you should carefully consider its cybersecurity credentials. After all, a quick, efficient website that loses its users’ trust due to lax security measures won’t be very successful.

The significance of dependable and secure hosting may already be clear to you if you are the owner website. If not, you might want to keep reading because we’ll break down the key security features you should consider when selecting a hosting solution and reveal the top 5 best secure ASP.NET hosting companies in terms of security.

Let’s get started.

What to look for in a hosting provider in terms of security

Most ASP.NET Core hosting companies will advertise a variety of features designed to keep your website or application (and, of course, your data) secure, but it’s important to carefully review your hosting package before you sign up because many of these features might not come as standard — some might, for example, only be available on higher-priced plans.

To avoid being caught off guard, make sure the hosting plan you choose includes all the security precautions you need. Your hosting company should at the very least provide the following security features:

• SSL Certificate:An SSL certificate is a particular kind of digital certificate that is used to verify a website’s legitimacy and encrypt data sent between the website and a user’s computer. It makes sure that all information exchanged between the server and the user is secure and private.
• Firewall:A firewall is a security system created to stop unauthorized access to a computer or private network (also known as a web application firewall). It is intended to filter traffic between various networks and stop malicious traffic from entering the protected system. It may be hardware- or software-based.
• Bot Protection: Bot protection is a type of security that employs automated tools and algorithms to find, keep an eye on, and prevent malicious bots from entering a network or website. Additionally, it can be used to identify and stop harmful behaviors like spamming and data scraping.
• Login Security: A set of safeguards used to make sure that only authorized users can access an online system is known as login security. To ensure the security of user accounts, two-factor authentication is frequently used, along with strong password guidelines and other security measures.
• User Access Management:User access management (UAM) is a security procedure used to regulate and keep track of user access to system resources. In order to ensure that access control policies are being followed, it typically entails creating user accounts, assigning permissions and privileges, and monitoring user activity.
• End-to-End Encryption: End-to-end encryption is a type of communication where only the people who are supposed to read the data can do so. It is typically used to protect sensitive data by ensuring that only the intended recipients can access the data, such as financial information or medical records.
• Two-Factor Authentication: Users must supply two pieces of information as part of a security procedure called two-factor authentication (2FA) in order to access a system or service. Most frequently, a password and a code are sent to the user’s mobile device for these two pieces of information.

In spite of the fact that the number of security features a company needs may vary depending on a variety of factors, including the nature of the company, the sensitivity of its data, the make-up of its workforce, etc., cybersecurity best practice calls for having multiple layers of defense in place.

The five ASP.NET Core hosting companies listed below are the ones we believe provide your company with the best overall security.

1. ASPHostPortal

ASPHostPortal is a Windows hosting service that also provides ASP.NET Core hosting. It is a simple, one-click hosting platform with more than 10,000 global servers. Dedicated firewalls, continuous real-time monitoring, automated backups, and regular security patching are just a few of the impressive range of security features it offers to keep your website or app safe from the newest threats. Enterprise-level security with cutting-edge defense against threats from distributed denial-of-service (DDoS) attacks is what ASPHostPortal promises through its partnership with the sector-leading CDN provider Cloudflare (the ASPHostPortal Enterprise add-on is included as standard).

Security features include:

• Free SSL certificate
• Automated backups
• Web Application Firewall (WAF)
• End-to-end encryption
• Malcare bot protection
• Two-factor authentication (2FA)
• Cloudflare Enterprise add-on

2. HostForLIFE.eu

With a variety of shared and cloud hosting options, HostForLIFE.eu was established in 2004 and now hosts more than 2 million domains globally. Although it is on the more “premium” end of the web hosting spectrum, its pricing reflects this. However, as with many other things, you get what you pay for. A dedicated IP, a free SSL certificate for each domain, and automatic daily data backups are standard features included with every HostForLIFE plan. HostForLIFE.eu is a complete but expensive solution that works best for big businesses with complicated cloud infrastructures and special security requirements.

Security features include:

• Free SSL certificate
• Automated daily backups
• Web Application Firewall (WAF)
• Regular patches and updates
• Real-time server monitoring
• AI anti-bot system
• Spam protection

3. UKWindowsHostASP.NET

When it comes to online security, UKWindowsHostASP.NET may not be as fully featured as some other ASP.NET Core hosting solutions, but it is still a very dependable and secure option that is advised for smaller businesses or those with simpler infrastructures. The affordable cloud hosting plans from UKWindowsHostASP.NET come with all of your essential security features as well as a few more sophisticated ones. All hosting plans include features like SSL certificates, automated backups, and multi-factor authentication (MFA), and for an additional fee, you can use the “UKWinShield” malware removal tool for additional security.

Security features include:

• SSL certificates
• Multi-factor authentication
• Automatic daily backups
• Domain privacy protection
• Firewalls for IIS
• ‘UKWinShield’ malware removal tool

4. WindowsASPNETHosting.in

Similar to UKWindowsHostASP.NET, WindowsASP.NETHosting.in is an inexpensive but surprisingly secure ASP.NET Core hosting option that is perfect for meeting the security requirements of small- to medium-sized businesses. In addition to offering a variety of inexpensive cloud hosting plans and virtual private server (VPS) hosting, WindowsASPNETHosting.in also integrates with Cloudflare to safeguard your website from DDoS attacks using a built-in DNS firewall. There are also tools like “SpamAssassin” (which detects and eliminates email spam) and “Bitninja,” a security suite that guards against automated assaults like cross-site scripting (XSS), malware, and brute-force attacks.

Security features include:

• Free SSL certificate
• Automated daily or weekly backups
• ‘SpamAssassin’ tool for removing email spam
• ‘Bitninja’ tool to prevents automated attacks
• Two-factor authentication
• Cloudflare DDoS firewall

5. DiscountService.biz

DiscountService.biz is well known for its quick speeds (it promises to make your servers run up to 20x faster), but that’s not all it has to offer: it also includes a range of strong security features, making it a great combination of speed and security. However, DiscountService does provide a variety of VPS hosting solutions with dedicated server resources. DiscountService does not currently offer traditional cloud hosting. When it comes to website security, DiscountService provides a dual firewall (guarding both the server and the network from threats), sophisticated DDoS protection, and a ‘HackScan’ tool that offers round-the-clock malware protection.

Security features include:

• Free SSL certificate
• DDoS protection
• Automatic backups (not included in the Standard plan)
• ‘HackScan’ 24/7 malware protection
• Server and network firewalls
• Server hardening
• Two-factor authentication

Conclusion

In website management, security issues can come from a variety of different places. Security is crucial, whether you choose a shared hosting plan or dedicated hosting. The performance of your website can be significantly impacted by vulnerabilities in plugins, themes, or other software, making it more vulnerable to hackers. Users can avoid some security issues by selecting a ASP.NET Core hosting provider with robust security measures, even though many security issues can be unpredictable.

Depending on the security options it offers, a ASP.NET host may have a direct impact on the security of a website. The features that hosting companies can offer to help secure your website range from firewall protection to SSL encryption. You can figure out which hosting company offers the best protection options by comparing the feature lists of various hosting companies.

A comprehensive set of security features should include a combination of the following:

• Your personal information can be protected from hackers by using domain security, which also stops them from stealing your credit card or domain login information.
• To stop unauthorized access to your website, firewall protection filters through incoming requests.
• Backups are a crucial element of a contingency plan. Automatically recover and restore your deleted or lost data.
• Your website’s traffic is secured, and endpoint communication is protected, thanks to an SSL certificate.
• DDoS mitigation will safeguard your website against unforeseen attacks and stop them from causing issues with downtime.
• Scanners for websites can assist in defending your website against malware and other harmful threats.

The security of your website depends on your choice of ASP.NET Core host, especially if you’re thinking about using a free or inexpensive service. Verify certifications and compliance standards to see if they have been met. By reading customer reviews, you can also learn more about their security procedures and background. This will help you stay away from disappointments and scams.

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.

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.