This is evident in the new Program and Startup classes, which, on the face of it, are much simpler than their ASP.NET Core 1.0 counterparts. In this post, I’ll take a look at the new WebHost.CreateDefaultBuilder()method, and see how it bootstraps your application.

Program and Startup responsibilities in ASP.NET Core 1.X

In ASP.NET Core 1.X, the Program class is used to setup the IWebHost. The default template for a web app looks something like this:

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

        host.Run();
    }
}

This relatively compact file does a number of things:

• Configuring a web server (Kestrel)
• Set the Content directory (the directory containing the appsettings.json file etc)
• Setup IIS Integration
• Define the Startup class to use
• Build(), and Run the IWebHost

The Startup class varies considerably depending on the application you are building. The MVC template shown below is a fairly typical starter template:

public class Startup  
{
    public Startup(IHostingEnvironment env)
    {
        var builder = new ConfigurationBuilder()
            .SetBasePath(env.ContentRootPath)
            .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
            .AddEnvironmentVariables();
        Configuration = builder.Build();
    }

    public IConfigurationRoot Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        // Add framework services.
        services.AddMvc();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole(Configuration.GetSection("Logging"));
        loggerFactory.AddDebug();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseBrowserLink();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
        }

        app.UseStaticFiles();

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

This is a far more substantial file that has 4 main reponsibilities:

• Setup configuration in the Startup constructor
• Setup dependency injection in ConfigureServices
• Setup Logging in Configure
• Setup the middleware pipeline in Configure

This all works pretty well, but there are a number of points that the ASP.NET team considered to be less than ideal.

First, setting up configuration is relatively verbose, but also pretty standard; it generally doesn’t need to vary much either between applications, or as the application evolves.

Secondly, logging is setup in the Configure method of Startup, after configuration and DI have been configured. This has two draw backs. On the one hand, it makes logging feel a little like a second class citizen – Configure is generally used to setup the middleware pipeline, so having the logging config in there doesn’t make a huge amount of sense. Also it means you can’t easily log the bootstrapping of the application itself. There are ways to do it, but it’s not obvious.

In ASP.NET Core 2.0 preview 1, these two points have been addressed by modifying the IWebHost and by creating a helper method for setting up your apps.

Program and Startup responsibilities in ASP.NET Core 2.0 preview 1

In ASP.NET Core 2.0 preview 1, the responsibilities of the IWebHost have changed somewhat. As well as having the same responsibilities as before, the IWebHost has gained two more:

• Setup configuration
• Setup Logging

In addition, ASP.NET Core 2.0 introduces a helper method, CreateDefaultBuilder, that encapsulates most of the common code found in Program.cs, as well as taking care of configuration and logging!

public class Program  
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
}

As you can see, there’s no mention of Kestrel, IIS integration, configuration etc – that’s all handled by the CreateDefaultBuilder method as you’ll see in a sec.

Moving the configuration and logging code into this method also simplifies the Startup file:

public class Startup  
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
        }

        app.UseStaticFiles();

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

This class is pretty much identical to the 1.0 class with the logging and most of the configuration code removed. Notice too that the IConfiguration object is injected into the class and stored in a property on the class, instead of creating the configuration in the constructor itself

This is new to ASP.NET Core 2.0 – the IConfiguration object is registered with DI by default. in 1.X you had to register the IConfigurationRoot yourself if you needed it to be available in DI.

My initial reaction to CreateDefaultBuilder was that it was just obfuscating the setup, and felt a bit like a step backwards, but in hindsight, that was more just a “who moved my cheese” reaction. There’s nothing magical about the CreateDefaultBuilder it just hides a certain amount of standard, ceremonial code that would often go unchanged anyway.

The WebHost.CreateDefaultBuilder helper method

In order to properly understand the static CreateDefaultBuilder helper method, I decided to take a peek at the source code on GitHub! You’ll be pleased to know, if you’re used to ASP.NET Core 1.X, most of this will look remarkably familiar.

public static IWebHostBuilder CreateDefaultBuilder(string[] args)  
{
    var builder = new WebHostBuilder()
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .ConfigureAppConfiguration((hostingContext, config) => { /* setup config */  })
        .ConfigureLogging((hostingContext, logging) =>  { /* setup logging */  })
        .UseIISIntegration()
        .UseDefaultServiceProvider((context, options) =>  { /* setup the DI container to use */  })
        .ConfigureServices(services => 
        {
            services.AddTransient<IConfigureOptions<KestrelServerOptions>, KestrelServerOptionsSetup>();
        });

    return builder;
}

There’s a few new methods in there that I’ve elided for now, which I’ll explore in follow up posts. You can see that this method is largely doing the same work that Program did in ASP.NET Core 1.0 – it sets up Kestrel, defines the ContentRoot, and sets up IIS integration, just like before. Additionally, it does a number of other things

• ConfigureAppConfiguration – this contains the configuration code that use to live in the Startupconfiguration
• ConfigureLogging – sets up the logging that use to live in Startup.Configure
• UseDefaultServiceProvider – I’ll go into this in a later post, but this sets up the built-in DI container, and lets you customise its behaviour
• ConfigureServices – Adds additional services needed by components added to the IWebHost. In particular, it configures the Kestrel server options, which lets you easily define your web host setup as part of your normal config.

I’ll look a closer look at configuration and logging in this post, and dive into the other methods in a later post.

Setting up app configuration in ConfigureAppConfiguration

The ConfigureAppConfiguration method takes a lambda with two parameters – a WebHostBuilderContextcalled hostingContext, and an IConfigurationBuilder instance, config:

ConfigureAppConfiguration(hostingContext, config) =>  
{
    var env = hostingContext.HostingEnvironment;

    config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

    if (env.IsDevelopment())
    {
        var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
        if (appAssembly != null)
        {
            config.AddUserSecrets(appAssembly, optional: true);
        }
    }

    config.AddEnvironmentVariables();

    if (args != null)
    {
        config.AddCommandLine(args);
    }
});

As you can see, the hostingContext parameter exposes the IHostingEnvironment (whether we’re running in “Development” or “Production”) as a property, HostingEnvironment. Apart form that the bulk of the code should be pretty familiar if you’ve used ASP.NET Core 2.0.

The one exception to this is setting up User Secrets, which is done a little different in ASP.NET Core 2.0. This uses an assembly reference to load the user secrets, though you can still use the generic config.AddUserSecrets<T> version in your own config.

In ASP.NET Core 2.0, the UserSecretsId is stored in an assembly attribute, hence the need for the Assembly code above. You can still define the id to use in your csproj file – it will be embedded in an assembly level attribute at compile time.

This is all pretty standard stuff. It loads configuration from the following providers, in the following order:

• appsettings.json (optional)
• appsettings.{env.EnvironmentName}.json (optional)
• User Secrets
• Environment Variables
• Command line arguments

The main difference between this method and the approach in ASP.NET Core 1.X is the location – config is now part of the WebHost itself, instead of sliding in through the backdoor so-to-speak by using the Startup constructor. Also, the initial creation and final call to Build() on the IConfigurationBuilderinstance happens in the web host itself, instead of being handled by you.

Setting up logging in ConfigureLogging

The ConfigureLogging method also takes a lambda with two parameters – a WebHostBuilderContext called hostingContext, just like the configuration method, and a LoggerFactory instance, logging:

ConfigureLogging((hostingContext, logging) =>  
{
    logging.UseConfiguration(hostingContext.Configuration.GetSection("Logging"));
    logging.AddConsole();
    logging.AddDebug();
});

The logging infrastructure has changed a little in ASP.NET Core 2.0, but broadly speaking, this code echoes what you would find in the Configure method of an ASP.NET Core 1.0 app, setting up the Consoleand Debug log providers. You can use the UseConfiguration method to setup the log levels to use by accessing the already-defined IConfiguration, exposed on hostingContext.Configuration.

Customising your WebHostBuilder

Hopefully this dive into the WebHost.CreateDefaultBuilder helper helps show why the ASP.NET team decided to introduce it. There’s a fair amount of ceremony in getting an app up and running, and this makes it far simpler.

But what if this isn’t the setup you want? Well, then you don’t have to use it! There’s nothing special about the helper, you could copy-and paste its code into your own app, customise it, and you’re good to go.

That’s not quite true – the KestrelServerOptionsSetup class referenced in ConfigureServices is currently internal, so you would have to remove this. I’ll dive into what this does in a later post.

Summary

This post looked at some of the differences between Program.cs and Startup.cs in moving from ASP.NET Core 1.X to 2.0 preview 1. In particular, I took a slightly deeper look into the new WebHost.CreateDefaultBuilder method which aims to simplify the initial bootstrapping of your app. If you’re not keen on the choices it makes for you, or you need to customise them, you can still do this, exactly as you did before. The choice is yours!

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.