ASP.NET Core.

ASP.NET Core is cross-platform and fast, and it ships with the core pieces most web apps need. The same app runs on Windows, Linux and macOS.

Its built-in Kestrel server is lightweight and handles many concurrent connections. The request pipeline is modular, so you add only the middleware your app needs and configure each piece.

Dependency injection is built in, which keeps classes loosely coupled and easy to unit test. Environment-based configuration, logging and security features such as authentication are built in too.

It also suits the cloud, since apps can run in Docker containers or deploy straight from Visual Studio to Azure App Service. As an open-source project, it has active community support and frequent updates.

The Startup class configures an ASP.NET Core app's services and its request pipeline when the app starts. The host calls its two methods, ConfigureServices first:

• ConfigureServices registers services, such as MVC, EF Core and logging, with the dependency injection container.
• Configure builds the request pipeline by adding middleware in order.

Before .NET 6 every app needed one. Since .NET 6, project templates do the same setup in Program.cs with WebApplication.CreateBuilder, and there is no Startup class. A Startup class still works in newer versions, but Microsoft no longer recommends it.

ConfigureServices registers the app's services with the dependency injection container. The host calls it before Configure, so every service it adds is ready when the request pipeline is built.

Framework features such as MVC, Razor Pages and Entity Framework Core register through Add{Service} extension methods, like AddControllersWithViews and AddDbContext. Your own services go in the same place, each with a lifetime set by AddTransient, AddScoped or AddSingleton. Configuration options are usually set here too.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
}

In .NET 6 and later templates there is no ConfigureServices method. The same registrations go on builder.Services in Program.cs, before builder.Build().

The Configure method builds the app's HTTP request pipeline by adding middleware components one after another. Requests pass through the middleware in the order it was added, and responses pass back in reverse order, so that order matters.

The runtime passes in an IApplicationBuilder, and each Use... call adds a component. Other services, such as IWebHostEnvironment, can be added as extra parameters, which lets the pipeline differ between Development and Production.

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

    app.UseStaticFiles();
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

Here the exception handler comes first, so it catches errors from everything after it. Authentication runs before authorization, and both sit between routing and endpoints. In .NET 6 and later, these calls follow builder.Build() in Program.cs instead.

ASP.NET Core reads settings from several configuration providers and merges them into one set of key-value pairs. When two sources set the same key, the source loaded later wins.

The default sources load in this order, so each one overrides the ones before it:

1. appsettings.json, the main settings file.
2. An environment file such as appsettings.Development.json.
3. User secrets, in the Development environment only.
4. Environment variables.
5. Command-line arguments.

So an environment variable overrides the JSON files, and a command-line argument overrides everything.

Settings are hierarchical. A key such as Logging:LogLevel:Default reads a nested JSON value, and environment variables write the colon as a double underscore. You read values through IConfiguration, or bind a section to a strongly typed class with the options pattern.

appsettings.json is the app's main settings file. It holds configuration data, such as connection strings and logging levels, in JSON format.

It is the base layer of configuration. An environment file such as appsettings.Production.json overrides its keys, and user secrets, environment variables and command-line arguments override both. By default both files reload when they change, so a saved edit takes effect without a restart.

Code reads a nested value with a colon path, such as Logging:LogLevel:Default. Never store passwords or other secrets in this file, because it often ends up in source control.

Create one settings file per environment, such as appsettings.Development.json and appsettings.Production.json, and set the environment name on each machine. At startup the app loads appsettings.json first, then the file for the current environment, whose keys override the base file.

The environment name comes from the ASPNETCORE_ENVIRONMENT or DOTNET_ENVIRONMENT variable. When neither is set, the app runs as Production. Locally, the launch profile in launchSettings.json usually sets it to Development.

Code can also branch on the environment:

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

Keep secrets out of these files. Production secrets belong in a controlled store such as Azure Key Vault.

ASP.NET Core logs through the built-in ILogger API. You inject ILogger<T> into a class, and the type's name becomes the log category, which helps you filter and search the logs.

public class HomeController : Controller
{
    private readonly ILogger<HomeController> _logger;
    public HomeController(ILogger<HomeController> logger)
    {
        _logger = logger;
    }

    public IActionResult Index()
    {
        _logger.LogInformation("Index page requested");
        return View();
    }
}

Each message goes to every configured logging provider. WebApplication.CreateBuilder adds the Console, Debug and EventSource providers, plus EventLog on Windows. Third-party frameworks such as Serilog or NLog plug in as providers too.

Write messages as templates with named placeholders, such as "Getting item {Id}", rather than building the string yourself. Providers then store the values as fields, which is structured logging.

Minimum levels per category go in the Logging section of appsettings.json, and the default level is Information.

Kestrel is the default, cross-platform web server for ASP.NET Core. It is lightweight and built for high performance, handling many concurrent connections. It supports HTTP/1.1, HTTP/2 and HTTP/3.

Kestrel can face the internet on its own, or sit behind a reverse proxy such as IIS, Nginx or Apache. Both setups are supported. A proxy adds a layer of security and configuration in production. It can also handle HTTPS certificates and load balancing, and let several apps share one IP address and port.