Create a Named HTTPClient

Create an ASP.NET Core Project

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary

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

While caching is a great thing, you must ensure the client is always running the latest version of the application. I mean, when you deploy the next version of the website, you don’t want the client to use an obsolete cached version of a file.

Versioned URL (Cache buster)

To ensure the user always uses the latest version of a file, we must have a unique URL per version of a file. There are many strategies:

• Use the query string: https://sample.com/file.js?v=123
• Rename the file: https://sample.com/file.123.js
• Create a directory: https://sample.com/123/file.js

ASP.NET Core provides a mechanism using a TagHelper to append the version with the query string. It supports the most common HTML tags that target a static resource: script, link and img. All you have to do is append asp-append-version="true" to the tag:

<link rel="stylesheet" href="~/css/site.css" asp-append-version="true" />
<script src="~/js/site.js" asp-append-version="true"></script>
<img src="~/images/banner1.svg" asp-append-version="true" />

This will produce:

<link rel="stylesheet" href="/css/site.css?v=1wp5zz4e-mOPFx4X2O8seW_DmUtePn5xFJk1vB7JKRc" />
<script src="/js/site.js?v=EWaMeWsJBYWmL2g_KkgXZQ5nPe-a3Ichp0LEgzXczKo"></script>
<img src="/images/banner1.svg?v=GaE_EmkeBf-yBbrJ26lpkGd4jkOSh1eVKJaNOw9I4uk" />

The version is the SHA256 of the file encoded in base64. Of course, the hash is computed only once per file and stored in an IMemoryCache.

The URL of files are now unique and will change when the file change, so we can add a cache header to the response to indicate the client that the file can be stored in cache forever.

Response headers

To indicate the browser to store the file in its cache, we must send the Cache-control header and the Expires header for HTTP/1.0 compatibility. To add these headers, we use the OnPrepareResponse callback of the StaticFilesOptions. Let’s modify the Startup.cs file:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseStaticFiles(new StaticFileOptions
    {
        OnPrepareResponse = context =>
        {
            // Cache static file for 1 year
            if (!string.IsNullOrEmpty(context.Context.Request.Query["v"]))
            {
                context.Context.Response.Headers.Add("cache-control", new[] { "public,max-age=31536000" });
                context.Context.Response.Headers.Add("Expires", new[] { DateTime.UtcNow.AddYears(1).ToString("R") }); // Format RFC1123
            }
        }
    });

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

You can check the headers are sent by using the Developer Console:

Conclusion

Using HTTP caching is important for performance reasons (client and server sides). With ASP.NET Core, you can take advantage of the provided TagHelpers to generate a versioned URL, and change the default configuration of the StaticFilesMiddleware to add the Cache-control header for these URLs.

Before we start it, please make sure you have installed MySQL 5.7, .NET Core, Visual Studio, and also Sakila sample database.

Let’s Get Started

1. The first step is to create ASP.NET Core Web Application and you can name it. For example, we use MvcSakilaCore.

2. Select Web Application template and No Authentication.

3. You will see the project below:

4. Press F5 to run the application:

5. Create a new folder named “Models” where it will store the database access:

6. Installing MySQL Connector/NET Core Package

7. Add Connection string like below

8. Adding data modal classes.

For this example a Film class will be used. It contains the database fields as properties we want to show in our application.

using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Configuration;
using MySql.Data.MySqlClient;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace MvcSakilaCore.Models
{
  public class Film
  {
    private SakilaContext context;

    public int FilmId { get; set; }

    public string Title { get; set; }

    public string Description { get; set; }

    public int ReleaseYear { get; set; }

    public int Length { get; set; }

    public string Rating { get; set; }
  }
}

Create a new SakilaContext class that will contains the connections and Sakila database entities:

using MySql.Data.MySqlClient;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.Extensions.DependencyInjection;

namespace MvcSakilaCore.Models
{
  public class SakilaContext
  {
    public string ConnectionString { get; set; }

    public SakilaContext(string connectionString)
    {
      this.ConnectionString = connectionString;
    }

    private MySqlConnection GetConnection()
    {
      return new MySqlConnection(ConnectionString);
    }

    public List<Film> GetAllFilms()
    {
      List<Film> list = new List<Film>();

      using (MySqlConnection conn = GetConnection())
      {
        conn.Open();
        MySqlCommand cmd = new MySqlCommand("SELECT * FROM film", conn);
        using (MySqlDataReader reader = cmd.ExecuteReader())
        {
          while (reader.Read())
          {
            list.Add(new Film()
            {
              FilmId = reader.GetInt32("film_id"),
              Title = reader.GetString("title"),
              Description = reader.GetString("description"),
              ReleaseYear = reader.GetInt32("release_year"),
              Length = reader.GetInt32("length"),
              Rating = reader.GetString("rating")
            });
          }
        }
      }

      return list;
    }
  }
}

In order to be able to use our SakilaContext it’s required to register the instance as a service in our application. To do this add the code line in the Startup.cs file:

9. Adding Film Controller

In Solution Explorer, right-click Controllers > Add > New Item… > MVC Controller Class. Name the controller FilmsController:

Change the FilmsController code to this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using MvcSakilaCore.Models;

// For more information on enabling MVC for empty projects, visit http://go.microsoft.com/fwlink/?LinkID=397860

namespace MvcSakilaCore.Controllers
{
  public class FilmsController : Controller
  {
    // GET: /<controller>/
    public IActionResult Index()
    {
      SakilaContext context = HttpContext.RequestServices.GetService(typeof(MvcSakilaCore.Models.SakilaContext)) as SakilaContext;

      return View(context.GetAllFilms());
    }
  }
}

10. Creating the Films View

Start creating the Films folder under Views:

In Solution Explorer, right click Views > Films > Add > New Item… > ASP.NET > MVC View Page

Add the following code into the new Index.cshtml view file:

@model IEnumerable<MvcSakilaCore.Models.Film>
@{
  ViewBag.Title = "Films";
}
<h2>Films</h2>
<table class="table">
  <tr>
    <th>Film ID</th>
    <th>Title</th>
    <th>Description</th>
    <th>Release Year</th>
    <th>Length</th>
    <th>Rating</th>
  </tr>
  @foreach (var item in Model)
  {
    <tr>
      <td>
        @Html.DisplayFor(modelItem => item.FilmId)
      </td>
      <td>
        @Html.DisplayFor(modelItem => item.Title)
      </td>
      <td>
        @Html.DisplayFor(modelItem => item.Description)
      </td>
      <td>
        @Html.DisplayFor(modelItem => item.ReleaseYear)
      </td>
      <td>
        @Html.DisplayFor(modelItem => item.Length)
      </td>
      <td>
        @Html.DisplayFor(modelItem => item.Rating)
      </td>
    </tr>
  }
</table>

Before run the application, add the Films path to the running url.

In Solution Explorer, right click MvcSakilaCore > Properties > Debug > Launch URL > Films:

Run the application (press F5) and the Films list should be displayed:

In this post I show how you can replace the Razor views for the default UI, without taking ownership of the business logic stored in the Razor Page PageModel code-behind files. I show how you can use the ASP.NET Core Identity scaffolder to generate the replacement Razor Pages initially, but customise these to use the existing, default, PageModels.

ASP.NET Core Identity

ASP.NET Core Identity is a series of services that provide functionality for managing and signing in users. You can use the Identity services to (among other things):

ASP.NET Core Identity is a series of services that provide functionality for managing and signing in users. You can use the Identity services to (among other things):

• Create users, and provide sign-in functionality
• Secure passwords using best practice, strong, hashing algorithms
• Generate short-lived tokens for email confirmation or multi-factor authentication,
• Enable auto-lockout of users to prevent brute-force attacks.
• Allow logging in with third-party providers like Google and Facebook.

The Identity services provide APIs for achieving all these things, but you still have to arrange them all in the right order. You also have to write the UI that users use to interact with the services. Obviously, that’s a huge investment, and is working with sensitive data, so you have to be very careful not to introduce any security holes.

Prior to ASP.NET Core 2.1, your best bet for implementing this was to use the UI generated from the Visual Studio templates. Unfortunately, using templates means that your UI is fine initially, but you then have a lot of code to maintain. If a bug is found in the templates, you have to go and update it yourself.

Luckily, ASP.NET Core 2.1 introduced a default UI Razor Class Library that meant you could benefit from the same UI, without having dozens of Razor Pages in your application to maintain. If a bug is found in the UI, the NuGet package can be updated, and you seamlessly get the bug fix, and all is great.

Customising the default UI

Of course, using the default UI means: you have to use the default UI. I think it’s generally unlikely that users will want to use the default UI in its entirety, unless you’re building internal apps only, or creating a “throwaway” app. For a start, the login and register pages include references to developer documentation that most people will want to remove:

Even though the UI is contained in a Razor Class Library, you can “overwrite” individual pages, by placing your own Razor Pages in a “magic” location in your project. For example, to override the register page, you can create a Razor Page at Areas/Identity/Pages/Register.cshtml:

A valid concern would be “how do I know which pages I can override?”. Luckily there’s a .NET Core tool you can use to scaffold pages from Identity in the correct locations, along with supporting files.

Scaffolding Identity files with the .NET CLI

The documentation for scaffolding Identity pages is excellent, so I’ll just run through the basics with the .NET CLI here. You can also use Visual Studio, but be sure to follow steps 1-3 below, otherwise you get weird random errors when running the scaffolder.

1. Add all the required packages to your application. If you’re already using EF Core in your app, then you may already have some of these, but make sure they’re all there, as missing packages can cause frustrating errors locally

dotnet add package Microsoft.VisualStudio.Web.CodeGeneration.Design
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
dotnet add package Microsoft.AspNetCore.Identity.UI
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

Also make sure that the installed package versions match your project version, for example .NET Core 3.1 projects should use packages starting 3.1.x.

2. Confirm your project builds without errors. If it doesn’t you’ll get errors when scaffolding files.

3. Install the code generator tool globally using dotnet tool install -g dotnet-aspnet-codegenerator.

4. Run dotnet aspnet-codegenerator identity -lf from the project folder (not the solution folder), to see the list of files you can scaffold:

>  dotnet aspnet-codegenerator identity -lf
Building project ...
Finding the generator 'identity'...
Running the generator 'identity'...
File List:
Account._StatusMessage
Account.AccessDenied
Account.ConfirmEmail
Account.ConfirmEmailChange
Account.ExternalLogin
Account.ForgotPassword
Account.ForgotPasswordConfirmation
Account.Lockout
... 25 more not shown!

In this case, I’m going to scaffold the Account.Register page, and remove the external login provider section completely.

You can create a Razor Pages app using the default UI by running dotnet new webapp -au Individual -uld

If you’re scaffolding into a project that’s configured to use the default UI, you will already have an EF Core IdentityDbContext in your application. Pass the fully namespaced name of the context in the following command, using the -dc switch, when scaffolding your files:

dotnet aspnet-codegenerator identity -dc TestApp.Data.ApplicationDbContext --files "Account.Register"

After running this command, you’ll find a bunch more files in the Areas/Identity folder:

The generated pages override the equivalents in the default UI package, so any changes you make to Register.cshtml will be reflected in your app. For example, I can delete the external login provider section entirely:

Remove your liabilities – deleting the scaffolded PageModel

I don’t want that code, so I’m just going to delete it! As I’m only going to make changes to the Razor views, I can delete the following files:

• Areas/Identity/Pages/Account/Register.cshtml.cs — this is the PageModel implementation I don’t want to have to maintain
• Areas/Identity/Pages/Account/ViewImports.cshtml — No longer necessary, as there’s nothing in the namespace it specifies now
• Areas/Identity/Pages/_ValidationScriptsPartial.cshtml — A duplicate of the version included in the default UI. No need to override it
• Areas/Identity/Pages/IdentityHostingStartup.cs — Doesn’t actually configure anything, so can be deleted

Additionally, you can update Areas/Identity/Pages/ViewImports.cshtml to remove the project-specific namespaces, to leave just the following:

@using Microsoft.AspNetCore.Identity
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

At this point, your app won’t compile. The Register.cshtml page will complain that you’ve specified a now non-existent RegisterModel as the PageModel for the Razor Page:

The final step is to update the @page directive to point to the original RegisterModel that’s included with the default Identity UI, referenced in full in the example below:

@page
@model Microsoft.AspNetCore.Identity.UI.V4.Pages.Account.Internal.RegisterModel
@{
    ViewData["Title"] = "Register";
}

This is the magic step. Your application will now compile, use your custom Razor views, but use the original Razor Pages PageModels that are part of the default UI! That’s much less code to maintain, and less chance to screw something up in your Identity pages

What are the downsides?

So what are the downsides of this approach? The only one I can really think of is that you’re very tightly tied to the PageModels in the original Identity UI, so you have to be sure that any updates that are made to the Identity UI are reflected in your Razor Page templates as appropriate. The big advantage is that if the default UI package is updated and it doesn’t make any breaking changes to the Razor templates, then you get the updates with no friction at all.

Another danger is that the inability to customise the PageModel may encourage you to do slightly janky things like @inject-ing services into the Razor views that shouldn’t be there, and adding additional logic into the Razor views. I’m not suggesting you should do this. If you _do_ need to change the behaviour of the page handlers, then you should just go ahead and take ownership of that code. The point is that this technique is useful when you don’t need to change the page handler logic.

Summary

In this post I gave some background on ASP.NET Core Identity and the default UI Razor Class Library that provides over 30 Razor Pages “for free”. I then showed how you could use the scaffolder tool to override one of these pages when you want to change the Razor template.

The downside of this default approach is that you now have to maintain the page handlers for the scaffolded pages. That’s 100s of lines of code per page that you must keep up to date when a new package version is released.

I showed how you can avoid that burden by deleting the scaffolded PageModel file, and point your Razor template to the original PageModel that comes as part of the default UI. This lets you update your Razor templates without having to take ownership of the page handler logic, potentially giving you the best of both worlds.

I looked at many examples but found that none showed the complete implementation of the Generic Host that is implemented to run as a console, Linux daemon, and Windows Service all in one application.

Here we will be looking at extending sample_service_hosting app to run it as a console app, windows service, or Linux daemon as well as making it self installable windows service.

.Net Core provides IHostBuilder interface to configure and create host builder. In case of a console app, host builder will run await RunConsoleAsync() function. To host and run our Generic Host as Windows Service we will need to use IApplicationLifetime to register Start and Stop events.

For hosting our Generic Host in Linux daemon we are going to inject IApplicationLifetime into main service and register and handle Start and Stop events.

There are several ways we could go to extend it to run as Windows Service, console app and Linux daemon. One way is to have a separate .Net Core project that will host our sample generic host service for each case or allow the program to accept command line variables that specify how to run the program. We will implement the command line arguments.

Command-line options:

• -i    Install as Windows Service
• -u  Uninstall Windows Service
• -console Run as a console app
• -daemon Run as Linux daemon service
• -h  Show command line switch help

Let’s make Argument Parser

In order to parse the arguments passed to the application, we will implement an argument parser class, which will return HostAction enum that specifies how the application is going to start. The application will accept only one argument on its input. If more than one argument supplied or it is an invalid argument, it will show usage message. If no arguments supplied it will try to run as Windows Service.

HostAction enum

namespace VSC
{
    public enum HostAction
    {
        ShowUsage,
        InstallWinService,
        UninstallWinService,
        RunWinService,
        WinServiceStop,
        RunConsole,
        RunLinuxDaemon
    }
}

Argument Parser class – ArgsParser

namespace VSC
{
    internal class ArgsParser
    {
        private string[] _args = null;
        public ArgsParser(string[] args)
        {
            _args = args;
        }

        public HostAction GetHostAction()
        {
            HostAction action = HostAction.ShowUsage;

            if(_args == null || _args.Length == 0)
            {
                action = HostAction.RunWinService;
            }
            else if(_args.Length > 1)
            {
                action = HostAction.ShowUsage;
            }
            else
            {
                string argument = _args[0];

                if(argument == "-i")    // install
                {
                    action = HostAction.InstallWinService;
                }
                else if(argument == "-u")   // uninstall
                {
                    action = HostAction.UninstallWinService;
                }
                else if(argument == "-console")
                {
                    action = HostAction.RunConsole;
                }
                else if (argument == "-daemon")
                {
                    action = HostAction.RunLinuxDaemon;
                }
            }

            return action;
        }
    }
}

Let’s make HostedService class

At the moment sample_service_hosting app creates host builder by calling CreateHostBuilder() from the Main function. We need to introduce a class that will perform an action depending on what HostAction returned by ArgsParser. We will call it HostedService class. It will have an async Run function that will start different action.

For now let’s implement run as a console, run as Linux daemon and show usage actions. Function CreateHostBuilder() will be moved from Program.cs to HostedService class.

HostedService class

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using NLog.Extensions.Hosting;

namespace VSC
{
    internal class HostedService
    {
        private static NLog.Logger _logger = NLog.LogManager.GetCurrentClassLogger();

        private ArgsParser _argsParser = null;

        public HostedService(ArgsParser argsParser)
        {
            _argsParser = argsParser;
        }

        public async Task Run(string[] args)
        {
            if (_argsParser != null)
            {
                var builder = this.CreateHostBuilder(args);
                
                if(builder == null) return;

                switch (_argsParser.GetHostAction())
                {
                    case HostAction.InstallWinService:
                    {
                        
                    }
                    break;
                    case HostAction.UninstallWinService:
                    {
                        
                    }
                    break;
                    case HostAction.RunWinService:
                    {
                        
                    }
                    break;
                    case HostAction.RunConsole:
                    {
                        try
                        {
                            await builder.RunConsoleAsync();
                        }
                        catch(Exception ex)
                        {
                            _logger.Error("Could not run as console app. " + ex.Message);
                            ShowUsage();
                        }
                    }
                    break;
                    case HostAction.RunLinuxDaemon:
                    {
                        try
                        {
                            await builder.Build().RunAsync();
                        }
                        catch(Exception ex)
                        {
                            _logger.Error("Could not start as Linux daemon service. " + ex.Message);
                            ShowUsage();
                        }
                    }
                    break;
                    default:
                    {
                        ShowUsage();
                    }
                    break;
                } 
            }   
        }

        private void ShowUsage()
        {   
            Console.WriteLine("Options:\n"
                        + "  'no options'\tStart Windows Service\n"
                        + "  -i\t\tInstall as Windows Service\n"
                        + "  -u\t\tUninstall Windows Service\n"
                        + "  -console\tRun as console app\n"
                        + "  -daemon\t Run as Linux daemon service\n"
                        + "  -h\t\tShow command line switch help\n");
        }
        private IHostBuilder CreateHostBuilder(string[] args)
        {
            try
            {
                var builder = new HostBuilder()
                    .UseNLog()
                    .ConfigureAppConfiguration((hostingContext, config) =>
                    {
                        config.SetBasePath(Directory.GetCurrentDirectory());
                        config.AddJsonFile("appsettings.json", optional: true);
                        config.AddJsonFile(
                            $"appsettings.{hostingContext.HostingEnvironment.EnvironmentName}.json", 
                            optional: true);
                        config.AddCommandLine(args);
                    })
                    .ConfigureServices((hostContext, services) =>
                    {
                        services.AddHostedService<Services.SampleService>();
                        services.Configure<HostOptions>(option =>
                        {
                            option.ShutdownTimeout = System.TimeSpan.FromSeconds(20);
                        });
                    })
                    .ConfigureLogging((hostingContext, logging) => 
                    {
                        logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
                        logging.AddConsole();
                    });

                return builder;
            }
            catch { }

            return null;
        }
    }
}

In Program.cs we change code as follows.

Program.cs

using System.Threading.Tasks;

namespace VSC
{
    class Program
    {   
        static async Task Main(string[] args)
        {
            ArgsParser argsParser = new ArgsParser(args);

            HostedService service = new HostedService(argsParser);
            await service.Run(args);
        }
    }
}

Let’s Make it self installable Windows Service

Now we got to the point of making our sample app to run as Windows Service. As Software Developer we always try to make the life of our users easier. If the app will be able to self install/uninstall as windows service our users will be much happier than trying to do that themselves.

We will start in the external process sc.exe service controller tool with parameters to install/uninstall/stop service. Example:

• sc.exe create “service_name” displayname= “service_name” binpath= “path to exe file”
• sc.exe delete “service_name”
• sc.exe stop “service_name”

WinServiceInstaller class will be responsible for running an external process and notifying of the progress. We will use WinService class to handle Start, Stop events and use extension functions to inject our WinService class into our Generic Host Builder.

WinService class

using System;
using System.ServiceProcess;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;

namespace VSC
{
    public class WinService : ServiceBase, IHostLifetime
    {
        public static string WinServiceName = "Default Service Name";
        private readonly TaskCompletionSource<object> _delayStart = new TaskCompletionSource<object>();

        private IApplicationLifetime ApplicationLifetime { get; }

        public WinService(IApplicationLifetime applicationLifetime)
        {
            this.ServiceName = WinServiceName;

            ApplicationLifetime = applicationLifetime ?? throw new ArgumentNullException(nameof(applicationLifetime));
        }        

        public void Start()
        {
            try
            {
                Run(this); // This blocks until the service is stopped.
                _delayStart.TrySetException(new InvalidOperationException("Stopped without starting"));
            }
            catch (Exception ex)
            {
                _delayStart.TrySetException(ex);
            }

            this.OnStart(null);
        }

        public Task StopAsync(CancellationToken cancellationToken)
        {
            Stop();
            return Task.CompletedTask;
        }

        public Task WaitForStartAsync(CancellationToken cancellationToken)
        {
            cancellationToken.Register(() => _delayStart.TrySetCanceled());
            ApplicationLifetime.ApplicationStopping.Register(Stop);

            new Thread(Start).Start(); // Otherwise this would block and prevent IHost.StartAsync from finishing.
            return _delayStart.Task;
        }

        protected override void OnStart(string[] args)
        {
            _delayStart.TrySetResult(null);
            base.OnStart(args);
        }

        protected override void OnStop()
        {
            ApplicationLifetime.StopApplication();
            base.OnStop();
        }
    }
}

WinServiceInstaller class

using System.Diagnostics;

namespace VSC
{
    public static class WinServiceInstaller
    {
        private static NLog.Logger _logger = NLog.LogManager.GetCurrentClassLogger();

        public static string APP_EXECUTABLE_PATH = string.Empty;
        private const string ServiceControllerEXE = "sc.exe";

        public delegate void WinServiceStatusHandler (string status);
        public static event WinServiceStatusHandler WinServiceStatus;

        public static void Uninstall(string serviceName)
        {
            Stop(serviceName); // stop service before uninstall

            RaiseWinServiceStatus("Uninstall Service");

            RunProcess(string.Format("delete \"{0}\"", serviceName));
        }

        private static void Stop(string serviceName)
        {
            RaiseWinServiceStatus("Stopping Service");

            RunProcess(string.Format("stop \"{0}\"", serviceName));            
        }

        public static void Install(string serviceName)
        {
            if(!string.IsNullOrEmpty(APP_EXECUTABLE_PATH))
            {
                RaiseWinServiceStatus("Install Service");

                string processArguments = string.Format("create \"{0}\" displayname= \"{1}\" binpath= \"{2}\"", serviceName, serviceName, APP_EXECUTABLE_PATH);
                
                RunProcess(processArguments);
            }
            else
            {
                _logger.Error("Cannot install service. Path to exe cannot be empty.");
            }
        }

        private static void RaiseWinServiceStatus(string status)
        {
            if(WinServiceStatus != null)
            {
                WinServiceStatus(status);
            }
        }

        private static void RunProcess(string arguments)
        {
            _logger.Trace("Arguments: " + arguments);

            var process = new Process();
            var processInfo = new ProcessStartInfo();
            processInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
            processInfo.FileName = ServiceControllerEXE;
            processInfo.Arguments = arguments;
            process.StartInfo = processInfo;
            process.Start();
            process.WaitForExit();
        }
    }
}

WinServiceExtensions static class

using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace VSC
{
    public static class WinServiceExtensions
    {
        internal static IHostBuilder UseServiceBaseLifetime(this IHostBuilder hostBuilder)
        {
            return hostBuilder.ConfigureServices((hostContext, services) => services.AddSingleton<IHostLifetime, WinService>());
        }

        public static Task RunAsWindowsServiceAsync(this IHostBuilder hostBuilder, CancellationToken cancellationToken = default)
        {
            return hostBuilder.UseServiceBaseLifetime().Build().RunAsync(cancellationToken);
        }
    }
}

We need to add to our project package reference System.ServiceProcess.ServiceController in order to compile WinService class.

dotnet add package System.ServiceProcess.ServiceController

Now in HostedService Run function, we can implement remaining switch cases that will Install, Uninstall and Run our app as windows service.

internal class HostedService
{
    ...

    public async Task Run(string[] args)
    {
        if (_argsParser != null)
        {
            var builder = this.CreateHostBuilder(args);
                
            if(builder == null) return;

            WinServiceInstaller.APP_EXECUTABLE_PATH = Utility.GetExecutingAssemblyLocation().Remove(Utility.GetExecutingAssemblyLocation().Length - 4) + ".exe";
                
            switch (_argsParser.GetHostAction())
            {
                case HostAction.InstallWinService:
                {
                    WinServiceInstaller.Install(WinService.WinServiceName);
                }
                break;
                case HostAction.UninstallWinService:
                {
                    WinServiceInstaller.Uninstall(WinService.WinServiceName);
                }
                break;
                case HostAction.RunWinService:
                {
                    try
                    {
                        await builder.RunAsWindowsServiceAsync();
                    }
                    catch(Exception ex)
                    {
                        _logger.Error("Could not start as windows service. " + ex.Message);
                        ShowUsage();
                    }
                }
                break;

    ...
}

You may have noticed that APP_EXECUTABLE_PATH is set by calling utility function GetExecutingAssemblyLocation in Utility class.

Utility static class

namespace VSC
{
    public static class Utility
    {
        public static string GetExecutingAssemblyLocation()
        {
            return System.Reflection.Assembly.GetExecutingAssembly().Location;
        }
    }
}

Let’s update the Main function

As the final step, we will update our Program.cs and add the logger to print status of our Windows Service. At the end before closing application, we also need to Flush logger and shut it down to release resource when our app will run as Linux daemon.

Program.cs

using System;
using System.Threading.Tasks;
using NLog;
using System.Reflection;

namespace VSC
{
    class Program
    {   
        private static Logger _logger = NLog.LogManager.GetCurrentClassLogger();

        static async Task Main(string[] args)
        {
            ArgsParser argsParser = new ArgsParser(args);

            WinService.WinServiceName = "The Sample Service Host";
            WinServiceInstaller.WinServiceStatus += new WinServiceInstaller.WinServiceStatusHandler(PrintWinServiceStatus);

            _logger.Info("Version: " + Assembly.GetEntryAssembly().GetName().Version.ToString());

            HostedService service = new HostedService(argsParser);
            await service.Run(args);

            _logger.Info("Shutting down logger...");
            // Flush buffered log entries before program exit; then shutdown the logger before program exit.
            LogManager.Flush(TimeSpan.FromSeconds(15));
            LogManager.Shutdown();
        }

        private static void PrintWinServiceStatus(string status)
        {
            _logger.Info(status);
        }
    }
}

Summary

Today we extended sample_service_hosting app with the ability to run as windows service and self install/uninstall itself to make it easier to deploy as windows service. We could go down the path of implementing separate projects: one for a console app, one for Linux daemon, one for windows service and one common project with our SampleService Host. We managed to do it all in one project with the use of ArgsParser class and extension functions to inject our Host into WinService.

When coupled with application monitoring and other performance tools, such as a profiler, ASP.NET becomes a powerful solution for building incredible apps.

Within the framework itself, there are myriad features to help you overcome common development challenges, do more with your apps, and boost performance.

13 features to build better applications with ASP.NET Core

1. Cross-platform & container support

With the introduction of .NET Core, you can now create ASP.NET applications and deploy them to Windows, Linux, and macOS. Microsoft and the community have put a huge effort into making Linux a first-class citizen for running ASP.NET.

Containers are eating the clouds these days. Docker, Kuberenetes and other technologies are all the rage. ASP.NET Core allows developers to utilize all of these new technologies. Microsoft Azure even has support for deploying your application to containers and Kubernetes.

2. High performance

Some say that performance is a critical feature of your software. I tend to agree! With the introduction of ASP.NET Core and the Kestrel web server, ASP.NET is touted as one of the fastest web application frameworks available. TechEmpower has some cool benchmarks you can check out.

The technology that powered the ASP.NET integrated pipeline and IIS was roughly 15 years old. It did everything and carried a lot of baggage with it. The new Kestrel web server was redesigned from the ground up to take advantage of asynchronous programming models, be much more lightweight, and fast!

3. Asynchronous via async/await

ASP.NET has excellent support for utilizing asynchronous programming patterns. Async is now implemented in all common .NET Framework classes and most third-party libraries. Most modern applications spend most of their time and CPU cycles waiting for database queries, web service calls, and other I/O operations to complete.

One of the reasons ASP.NET Core is faster is its extensive use of asynchronous patterns within the new MVC and Kestrel frameworks.

//mark the method as async
public async Task GetGWB()
{
    HttpClient hc = new HttpClient();
    //await keyword handles all the complexity of async threading and callbacks
    await hc.GetAsync("http://geekswithblogs.net/Default.aspx");
    return true;
}

4. Unified MVC & Web API frameworks

Before ASP.NET Core, developers were most commonly using the MVC and Web API frameworks. MVC was tailored to creating web applications that served up HTML. Web API was designed to create RESTful services using JSON or XML.

With ASP.NET Core, MVC and Web API have been merged together. There was always a lot of overlap with the two frameworks. MVC could always return JSON data instead of HTML. Combining them was a good move and simplifies development.

With ASP.NET Core we also have the new Razor Pages. They extend the MVC framework to allow encapsulating the controller and model aspects of a page together with two-way binding. They are sort of a replacement for WebForms while using the familiar Razor syntax.

5. Multiple environments and development mode

One of my favorite features is the new environment feature. It allows you to easily differentiate parts of your code for their behavior in development, staging, production, etc. There was no standard way to do this before ASP.NET Core.

Environments are perfect for using different CSS or Javascript files. Use your CDN in production, but local files during development. This is a snippet out of my Razor layout view.

    <environment names="Development">
        <script src="~/lib/jquery/dist/jquery.js"></script>
        <script src="~/lib/bootstrap/dist/js/bootstrap.js"></script>
        <script src="~/js/site.js" asp-append-version="true"></script>
    </environment>
    <environment names="Staging,Production">
        <script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-2.2.0.min.js"
                asp-fallback-src="~/lib/jquery/dist/jquery.min.js"
                asp-fallback-test="window.jQuery"
                crossorigin="anonymous"
                integrity="sha384-K+ctZQ+LL8q6tP7I94W+qzQsfRV2a+AfHIi9k8z8l9ggpc8X+Ytst4yBo/hH+8Fk">
        </script>
        <script src="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.7/bootstrap.min.js"
                asp-fallback-src="~/lib/bootstrap/dist/js/bootstrap.min.js"
                asp-fallback-test="window.jQuery && window.jQuery.fn && window.jQuery.fn.modal"
                crossorigin="anonymous"
                integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa">
        </script>
        <script src="~/js/site.min.js" asp-append-version="true"></script>
    </environment>

6. Dependency Injection

One of the great new features of ASP.NET Core is built in dependency injection. It is heavily used within ASP.NET MVC itself. It is the preferred way that things like logging contexts, database contexts, and other things are passed into your MVC controllers.

public class PaymentService: IPaymentService
{
  public ILogger Logger { get; }

  //automatically passes the logger factory in to the constructor via dependency injection
  public PaymentService(ILoggerFactory loggerFactory)
  {
    Logger = loggerFactory?.CreateLogger();
    if(Logger == null)
    {
      throw new ArgumentNullException(nameof(loggerFactory));
    }
    Logger.LogInformation("PaymentService created");
  }
}

7. WebSockets & SignalR

ASP.NET has first class support for WebSockets. This can be used to persist long running connections and communicate back and forth with the browser. SignalR is a full framework that is also available that makes it easy handle common scenarios.

8. Cross-Site Request Forgery (CSRF) Protection

Security is important. It is also one of those things that can be a lot of work to prevent certain types of attacks. CSRF is in referencing to hijacking users authenticated session to perform an action that they did not initiate.

For example, let’s pretend that you log in to your bank account and then navigate to a different website. If that other website could do a POST to your bank website to transfer funds, that would be a bad thing. It could potentially do that if your online session on the banking website is valid and the bank does not properly validate requests.

ASP.NET has a good framework that is available to prevent these types of attacks. It generates anti-forgery tokens.

9. “Self hosted” Web Applications

Sometimes you need to make a web application that will be deployed on to a desktop and not a server running IIS. Our free ASP.NET profiler, Prefix, is a perfect example of this. Its front end is all HTML that is loaded from an ASP.NET application running as a Windows Service.

You can create a self-hosted ASP.NET web application several different ways. In .NET 4.5 you could accomplish it by using Owin, Nancy, or WCF. For Prefix, we use ASP.NET Web API with Owin.

With ASP.NET Core, you can also use the standard Kestrel web server. One of the great advantages of .NET Core is that your web application is essentially a console application. IIS just sits in front of it as a reverse proxy. This means that you can also deploy your app only with kestrel for non-server based use cases, like Prefix.

10. Action Filters

One of the great features of ASP.NET is the support for extensible filters. This allows you to implement functionality that can be applied to an entire controller or action without modifying the action itself.

Filters are used to specify caching, error handling, authorization, or any custom logic you would like to implement.

using System;
using System.Web.Mvc;

namespace MvcApplication1.Controllers
{
     public class DataController : Controller
     {
          [OutputCache(Duration=10)]
          public string Index()
          {
               return DateTime.Now.ToString("T");
          }
     }
}

11. Extensible Output Caching

This feature allows ASP.NET to cache the output generated by a page and serve this cached content for future requests. It stores the data that is not updated frequently and outputs that specific data from a cached location.

ASP.NET makes it easy to specify how long any request should be cached via common HTTP headers. It also has support for caching output within the memory on your web server itself. You can even use Redis or other providers to handle your output caching.

12. Globalization and Localization

ASP.NET makes it easy to localize dates, numbers, and the text within your web application. If you want your application to be used across the globe, localization will be very important to you.

ASP.NET enables customizing your application for multiple languages via resource files. These resource files are considered as the central repository where all texts are kept, and web pages can read this resource file and get labels populated. There are two types of resources:

• Local Resources – specific for a page (i.e., there will be local resource file for every page)
• Global Resources – common for the whole website (i.e., one resource file accessed by all pages)

13. Swagger OpenAPI

If you are creating API applications, you want to make sure you are using Swagger. It makes it easy to document and test your APIs.

ASP.NET has historically provided built-in functionality that is pretty similar for SOAP web services created with WCF. If you are using Web API or MVC for RESTful APIs, you definitely want to use Swagger.

Conclusion

ASP.NET Core has been a nice upgrade over previous versions. In this article, we highlighted some of the key features you should be aware of. Some are new, some are just key features of ASP.NET that have existed for a while.

In this article, we’ll find a happy medium—we’ll look at how to get started with Angular using ASP.NET Core by following a simple recipe with clearly defined ingredients. We’ll start by walking through all of the ingredients necessary to make a successful project. Next we’ll follow the recipe, learning where each ingredient fits. Finally, the application will be fully baked and ready to serve with all of its cutting edge goodness.

The Ingredients

Prepping the ingredients is the most important part of any recipe. Let’s look at what we’ll need to be successful and why each item is important to our project.

ASP.NET Core

ASP.NET Core 1.1 is a next generation architecture for building scale-able .NET web applications that run on any platform. Web API was consolidated with MVC in ASP.NET Core, making it a great platform to host endpoints for our application’s data.

ASP.NET Core will act as the server component for the application. The responsibility of ASP.NET Core is to power core business logic, interact with a database and provide application services like: email, authentication, and SMS to name a few.

Node Package Manager (npm)

Many of the ingredients for this application will come from the JavaScript community. The dependencies needed for frontend development are all easily managed through npm either from the Command Line Interface (CLI) or from within Visual Studio.

Angular, TypeScript & Webpack

ASP.NET Core is capable of generating HTML for the client-side of the application on its own, but with the addition of Angular we can do so much more. Angular allows us to build rich interactive client-side applications using a component based architecture.

Using Angular requires some additional tooling since it relies heavily on TypeScript. To support Angular, we’ll be using Webpack to compile TypeScript, as well as to bundle and minify static resources.

dotnet CLI

Typically one would expect to use Visual Studio’s File > New project template to begin a new project. However, because of the cross platform nature of ASP.NET Core development we’ll be using the dotnet CLI, a command line tool used to generate .NET project templates. Since the command line is ubiquitous, it suits ASP.NET Core development because it can be used anywhere.

Kendo UI for Angular

Like any great chef would tell you, presentation matters. We’ll use Kendo UI for Angular to finish out the look of the application. With beautiful UI controls, Kendo UI for Angular delivers high performance Angular UI components without any jQuery dependencies.

Prep Work

Let’s begin by putting all of our ingredients in place. Some quick prep work can make sure that we stay clear of any hangups. This is critical, as the last thing you want to do is waste hours of precious time troubleshooting problems that have already been addressed by using newer versions.

Before beginning your next project, make sure the following tools are installed and you’re running the latest bits. You can find everything you’ll need below:

• NET Core installers

• npm-$ npm install npm@latest -g

The Recipe

We’ll start by installing the Microsoft ASP.NET Core JavaScript Services. JavaScript Services is a set of technologies for ASP.NET Core developers built by the ASP.NET team. It provides infrastructure that you’ll find useful if you use Angular/React/Knockout/etc. on the client, if you build your client-side resources using Webpack, or if you otherwise want to execute JavaScript on the server at runtime. We’ll be using a JavaScript Services project template installed by the dotnet CLI. The template will take care of the Angular, TypeScript and Webpack dependencies for us.

From the command line install the JavaScript Services templates:

dotnet new --install Microsoft.AspNetCore.SpaTemplates::*

Next, run the dotnet new angular command—using the angular parameter will specify the Angular template. The template will create a fully functioning starting point for your new application. Once the template has run, the dependencies will need to be restored by running dotnet restore. Once the dependencies are restored you can start up your new ASP.NET Core Single Page from within Visual Studio, or from the command line by calling dotnet run.

Navigating to the app in our browser shows us the template in action.

The Template

The JavaScript services template is pre-configured with Angular, TypeScript and Webpack. The application back-end is powered by ASP.NET Core, with Angular taking almost all responsibilities for the client-side. You’ll notice very little in the way of Views or .cshtml.

The client-side application source files are found in the ClientApp directory. Each folder under ClientApp contains the parts to a single component, a template (.html), component logic written in TypeScript (.ts), and optionally component styles (.css). These files will be compiled by Webpack prior to run-time. Webpack configuration files are included in the template. These configuration files define compilation, bundling and deployment to wwwroot.

In ClientApp a few sample components demonstrate how to use Angular. The counter is a component that shows how to wire up a button that increments a counter. Also included is a fetch-data component, this component shows how to consume data from an API endpoint.

Time to Bake

With the project scaffolding ready let’s modify some components. Working with components will get us familiar with the app’s structure and work-flow of the tooling. We’ll add robust UI components using Kendo UI for Angular to the existing app components.

First, Kendo UI works best with the latest version of Angular, so let’s update our Angular references:

npm install --save @angular/animations@latest @angular/common@latest @angular/compiler@latest 
@angular/core@latest @angular/forms@latest @angular/http @angular/platform-browser@latest 
@angular/platform-browser-dynamic@latest @angular/platform-server@latest @angular/router@latest

Next, we’ll add the Kendo UI dependencies to the project. Kendo UI for Angular is packaged and distributed as a set of discrete, scoped npm packages, which are available from npm.

It’s time to add Kendo UI components to the project. We’ll add the Kendo UI Button and Grid components from the command line using npm.

npm install --save @progress/kendo-angular-buttons @progress/kendo-angular-l10n @angular/animations

npm install --save @progress/kendo-angular-grid @progress/kendo-angular-dropdowns @progress/kendo-angular-
inputs @progress/kendo-angular-dateinputs @progress/kendo-data-query @progress/kendo-angular-intl 
@progress/kendo-angular-l10n @progress/kendo-drawing @progress/kendo-angular-excel-export 
@angular/animations

Next we’ll import the component directives into our source code. Because Kendo UI for Angular uses Ahead-of-Time Compilation (AoT), we’ll declare the modules in the app’s shared module. Open ClientApp/App/app.module.shared.ts and add the following declarations:

...;
import { ButtonsModule } from '@progress/kendo-angular-buttons';
import { GridModule } from '@progress/kendo-angular-grid'; 

imports: [     
     ButtonsModule,
     GridModule, ...,

Kendo UI just wouldn’t be complete without some nice styling. Let’s add the default Kendo UI theme to our project via npm.

npm install -S @progress/kendo-theme-default@2.38.1

The npm package deploys to our node_modules folder, however we’ll need the CSS file referenced in our project. To do this we’ll add a reference in webpack.vendor.config.js to the CSS that our app requires. Webpack is pre-configured to bundle CSS files into a single vendor.css file which is output to the wwwroot folder for deployment.

entry: { vendor: [ ..., '@progress/kendo-theme-default/dist/all.css',

Once the reference is added, we’ll need to run Webpack to rebuild vendor.css.

In package.json we’ll add the Webpack command for rebuilding vendor dependencies for the application.

"scripts": {
  "test": "karma start ClientApp/test/karma.conf.js",
  "webpack:vendor": "webpack --config webpack.config.vendor.js",
  ...

To run the script from npm execute npm run webpack:vendor from the command line.

Now that Kendo UI for Angular is installed, let’s replace a few components that are part of the samples. One of benefits of Kendo UI is that a single theme controls the style of all Kendo UI components, even simple controls like the button. Let’s modify the sample to use a Kendo UI button.

In ClientApp/app/components/counter/counter.component.html you’ll find a button that increments a counter. Replace the standard button with a Kendo UI Button.

<button kendoButton (click)="incrementCounter()" [primary]="true">Increment KUI</button>

Next, we’ll modify the fetch-data sample by utilizing the Kendo UI grid. Since Kendo UI has robust data binding capabilities this will be an easy task. In ClientApp/app/components/fetchdata/fetchdata.component.html a table has been explicitly defined using Angular templates.

<table class='table' *ngIf="forecasts">
  <thead>
    <tr>
       <th>Date</th>
       <th>Temp. (C)</th>
       <th>Temp. (F)</th>
       <th>Summary</th>
    </tr>
  </thead>
  <tbody> 

  <tr *ngFor="let forecast of forecasts">
    <td>{{ forecast.dateFormatted }}</td>
    <td>{{ forecast.temperatureC }}</td>
    <td>{{ forecast.temperatureF }}</td>
    <td>{{ forecast.summary }}</td>
  </tr>
  </tbody>
</table>

We can replace the entire template with a single kendo-grid component. At the absolute minimum we can bind the data property and the grid will generate the columns and headings.

<kendo-grid [data]="forecasts"></kendo-grid>

To further enhance the UI we can customize each column.

<kendo-grid [data]="forecasts">
  <kendo-grid-column field="dateFormatted" title="Date"></kendo-grid-column>
  <kendo-grid-column field="temperatureC" title="Temp. (C)"width="150"></kendo-grid-column>
  <kendo-grid-column field="temperatureF" title="Temp. (F)"width="150">
  </kendo-grid-column> <kendo-grid-column field="summary"title="Summary"></kendo-grid-column>
</kendo-grid>

Time To Serve

The ASP.NET Core JavaScript Services dotnet CLI template, combined with Kendo UI for Angular, provide a solid platform for dishing out modern web applications. Using the JavaScript Services generator makes short work of starting a new Angular project. It comes with everything needed for client and server side development and excellent samples to get you started. The growing library of Kendo UI for Angular components with world class features like data binding, internationalization and themes make a full course meal ready to serve. The completed starter project can be viewed on GitHub. Please remember this app requires the scoped Progress NPM registry to restore dependencies.

In this article, we will discuss using traditional .NET logging frameworks and some new changes in ASP.NET Core and .NET Core.

Third Party Logging Libraries for ASP.NET Core

The three most popular libraries for logging support .NET Core. If you are converting your application from ASP.NET to Core, you won’t have to make any code changes. Just upgrade to the latest NuGet packages. Although you may want to move your logging config to its own file since your web.config will now be gone in favor of the new appsetting.json.

Log4net

When .NET Core 1.0 launched, log4net had not been ported to support .NET Core (it has since). Their long delay in support for .NET Core is just one example of where log4net has been slow to keep up with new trends and features in logging frameworks. It may be the most popular framework, but NLog and Serilog are on the leading edge.

NLog

NLog has quickly become the second most popular framework for .NET logging. They had support for .NET Core when v1.0 came out and continue to rapidly add new features. NLog even works across Xamarin, Mono, and other runtimes. NLog is a safe bet if you are thinking about selecting a new logging framework for ASP.NET Core.

Serilog

Serilog was created to bring more structure to logging variables and objects. It has become very popular and continues to grow. It supports all the common logging features you would support, like configurable output targets and is much more modern than log4net.

Built-in ASP.NET Core Logging

ASP.NET Core now has a built-in logging framework that you can use. It is not as feature-rich as third party libraries. Let me give you a quick and dirty tour of the new ILoggerFactory that is built into .NET Core.

If you have created a brand new ASP.NET Core web application, you have likely seen these loggerFactory lines of code in your Startup class.

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

{

                loggerFactory.AddConsole(Configuration.GetSection("Logging"));

                loggerFactory.AddDebug();

                //removed the rest of the lines

}

You will also find some logging settings in the default appsettings.json.

{

  "Logging": {

    "IncludeScopes": false,

    "LogLevel": {

      "Default": "Debug",

      "System": "Information",

      "Microsoft": "Information"

    }

  }

}

If you run the default app, you can see it write out some details in the debug window in Visual Studio that shows when MVC actions happen and how long they take.

Microsoft.AspNetCore.Hosting.Internal.WebHost: Information: Request starting HTTP/1.1 GET http://localhost:29564/

Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker: Information: Executing action method ASPNetCore.Controllers.HomeController.Index (CoreSharedLib) with arguments () - ModelState is Valid

Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.ViewResultExecutor: Information: Executing ViewResult, running view at path /Views/Home/Index.cshtml.

Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker: Information: Executed action ASPNetCore.Controllers.HomeController.Index (CoreSharedLib) in 26.8787ms

Microsoft.AspNetCore.Hosting.Internal.WebHost: Information: Request finished in 60.9946ms 200 text/html; charset=utf-8

Disabling or Reducing the Built-in .NET Core Logging Messages

If you want to disable these built-in messages all together, you can simply remove the AddConsole() and AddDebug() methods. If you want to reduce how much they log then you can adjust their log levels.

For AddConsole() you will notice that you can pass into it Configuration.GetSection(“Logging”) which pulls the log levels from your appsettings.json configuration, or other custom providers you may be using. By setting a log level to “None” it will disable it. Just above is an example of an appsettings.json that I am referring to here.

AddDebug(), for some reason, does not support the same configuration-based initialization. You can instead specify a log level in your code directly, which I guess is fine since debug is really just meant for use in development and wouldn’t need to be configured differently in QA or production.

These log levels are all supported: None, Trace, Debug, Information, Warning, Error, Critical.

How to Redirect Internal .NET Core Logging to NLog or Serilog

You don’t have to use the built-in logging. You can – and I would probably recommend this – use NLog, Serilog, or log4net. If you want to capture the internal logging coming from .NET Core and send it to your separate logging framework, you can. You just have to configure it!

For NLog/Serilog, all you have to do is add one line of code in your Startup Configure() method. This adds a special logging provider for NLog/Serilog that redirects the messages.

loggerFactory.AddNLog();

or

loggerFactory.AddSerilog();

Using the New ILogger and ILoggerFactory in Your Code

Being able to see all of the .NET Core internal logging is cool, but what about my own logging?

One of the big additions to .NET Core is built-in dependency injection. You can use the ILoggerFactory via dependency injection in your own code as shown below.

public class HomeController : Controller

 {

        ILoggerFactory _loggerFactory;

 

        public HomeController(ILoggerFactory loggerFactory)

        {

            _loggerFactory = loggerFactory;

        }

        

        public string Ping()

        {

            var logger = _loggerFactory.CreateLogger("LoggerCategory");

            logger.LogInformation("Calling the ping action");

 

            return "pong";

        }

}

Now, when I execute this code I see similar logging as I showed before, but I also see my extra logging line.

LoggerCategory: Information: Calling the ping action

So, you can see how easy it is to use the new built-in ASP.NET Core logging via ILoggerFactory and dependency injection.

The new logging API currently supports the following built-in providers:

• Console
• Debug
• EventSource
• EventLog
• TraceSource
• Azure App Service

So if you have followed along this far, I’m sure you are wondering about how to make the built-in logging write to a file on disk. You have to use a 3rd party extension to do it.

How to Enable ASP.NET Core Logging to a File

Since .NET Core does not support logging to file directly, you will want to use an extension from NLog or Serilog that can route .NET Core logging to those libraries. Then you can take full advantage of their features. I am going to assume that they left a File writer option out because of the complexity it creates. It opens up a huge set of requirements around max file sizes, rolling files, deleting files, file writing performance, etc.

Read more: NLog Extensions

Read more: Serilog.Extensions.Logging.File

Using Serilog as an example, all you have to do is install their Extensions NuGet package and, with one line of code, do an AddFile in your Startup class. Now you have a log file on disk!

public void Configure(IApplicationBuilder app,

                          IHostingEnvironment env,

                          ILoggerFactory loggerFactory)

{

        loggerFactory.AddFile("Logs/mylog-{Date}.txt");

        //other code removed for example

}

Limitations of ASP.NET Core Logging Configuration

The built-in logging doesn’t provide much for configuration. All you can do is configure the logging level (Debug, Warning, Error, etc) by logging category name.

Viewing Your Application Errors and Logs

How to View Your Logs While Writing and Testing Code

You can use Prefix, Stackify’s free ASP.NET Profiler, to view all of your logging statements during development. Prefix can show you all of your logs, errors, SQL queries, HTTP calls, and much more.

How to View Your Logs in QA or Production

If you only send your logging to a file on disk, it can be pretty hard to get a lot of use out of them once you deploy your app to a server somewhere. You really need to centralize your logs with a log management system. This gives you the ability to do full-text searching across all of your logs for all applications and servers from one place.